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

Question

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

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

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

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

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

Редактировать : Смежные вопросы: Как назвать объект-оболочку базы данных?

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

Проверьте эту ссылку для более подробного обсуждения.