Что такое рекомендуемое соглашение об именах для классов в многоуровневом приложении?

У меня есть проблемы с именами моих классов/пространств имен/элементов управления.

В моей бизнес-библиотеке у меня есть пространство имен под названием Shopping. Он содержит следующие классы: ShoppingCartItem
ShoppingCart
ShoppingCartManager

В моем приложении ASP.net я хочу создать элемент управления, который графически представляет элементы экземпляра ShoppingCart. Обычно я бы назвал этот элемент управления ShoppingCart, но еще один класс под названием ShoppingCart? Конечно, компиляция и т.д. Работала бы, но я думаю, что она все еще уродлива. Я думаю, что у меня есть проблема, которую я называю своими бизнес-классами, что они должны представлять. Поскольку, когда дело доходит до уровня представления, я бы назвал элементы управления, которые должны представлять бизнес-класс тем же самым.

Я думаю, что я мог бы добавить суффикс типа "Просмотр", но я хочу сделать это правильно.

Что такое рекомендуемое назначение имен для многоуровневого приложения?
Как я могу назвать элемент управления, представляющий элементы ShoppingCart на уровне презентации?

Изменить: Вопросы, относящиеся: Как я могу назвать объект оболочки базы данных?

ОТВЕТЫ

Ответ 1

В парадигме MVC довольно часто встречаются Foo, FooView и FooController.

Вы можете решить, что проще вставить их в другую иерархию (Shopping.Model.Cart, Shopping.View.Cart). Он концептуально чист, но я думаю, что это довольно непроницаемо. Вместо этого вы можете использовать разные имена в разных пространствах имен (Shopping.View.CartView).

Хорошая среда IDE позволит вам перемещать/переименовывать вещи, тем не менее, поэтому не стоит тратить слишком много времени на беспокойство по поводу выбора идеального имени для чего-то. Более важно четко понимать, что вы моделируете и каковы его ограничения. Например...

  • Является ли Car экземпляром автомобиля или конкретной марки/модели автомобиля? Является ли мотоцикл a Car? Если вы собираетесь переименовать его в Vehicle, это велосипед для транспортного средства?
  • Является ли Item типом элемента, экземпляром элемента или quantity экземплярами элемента?
  • Является ли ShoppingCart просто списком элементов/величин или имеет другие функции? Объединяет ли он дубликаты элемента, суммируя количество?
  • Является ли список желаний специальным видом корзины покупок (тот, который вы еще не купили) или что-то еще?
  • Можете ли вы "сохранить" корзину покупок и получить цитату (чтобы вы могли распечатать ее, отнести к своему боссу, отменить его, а затем купить)? Где хранится цитата?

Ответ 2

Другие люди StackOverflow могут знать лучше, но, насколько я знаю, нет общепринятого или стандартного соглашения об именах, относящегося к многоуровневой архитектуре. Хотя я думаю, что вы на правильном пути: moreso, чем конкретное имя, выбирая подход и используя его последовательно, поможет сделать ваш код более удобным.

Ответ 3

Вы можете использовать пространство имен для разделения пользовательского интерфейса и бизнес-модели корзины покупок, например:

  • YourApp.Web.UI.ShoppingCart (веб-контроль вашей корзины покупок)
  • YourApp.BusinessEntity.ShoppingCart (класс вашей корзины покупок на уровне вашей бизнес-логики)

Когда вы создаете/используете объект корзины покупок, сначала не очевидно, будет ли объект элементом управления пользовательским интерфейсом или классом сущности, но ваша среда IDE (визуальная студия) предоставит вам intellisense при написании кода и подсказка, когда вы наводите указатель мыши на имя, которое может облегчить вашу проблему.

В качестве альтернативы, если вы действительно хотите облегчить вам глаза на чтение, вы можете использовать префикс при именовании вашего объекта:

  • YourApp.Web.UI.ShoppingCart uiShoppingCart;
  • YourApp.BusinessEntity.ShoppingCart beShoppingCart;

Ответ 4

Вы должны принять решение об условных обозначениях, которые вы собираетесь использовать, прежде чем начинать свой проект. В .NET Framework содержится ряд предложений по соглашениям об именах, вы можете найти предложения по соглашению об именах Visual Basic® в этом месте в документах:

мс-помощь://MS.VSCC/MS.MSDNVS/vbcn7/html/vaconVBNamingRules.htm

Важно принять решение и придерживаться набора соглашений об именах, а не ограничивать себя определенным. Также важно проанализировать влияние соглашений об именах, которые вы используете. Например, мне все же нравится префикс имен управления с типом элемента управления, потому что я могу набрать "txt" в редакторе кода, нажать Ctrl + Space и получить список всех элементов управления текстовыми полями в форме.

Ознакомьтесь с этой для более подробного обсуждения.