Соглашения об именах пространства имен в dotnet

Question

Я обычно использую это соглашение:

CompanyName.ApplicationName.Functionality

например,

Acme.EmailService
Acme.EmailService.Dal
Acme.EmailService.BusinessLogic
Acme.EmailService.BusinessLogic.ErrorHandling

, но там, где я сейчас работаю, они используют:

CompanyName.Functionality.ApplicationName

Acme.EmailService
Acme.Dal.EmailService
Acme.BusinessLogic.EmailService
Acme.BusinessLogic.EmailService.ErrorHandling

Последнее пространство имен мне кажется немного странным.Это подпапка проекта businesslogic, поэтому по умолчанию имя папки добавляется к пространству имен.

Я видел множество стандартов соглашения об именах, но ни один из них, похоже, не упоминал эту проблему.

Что такоеПлюсы и минусы каждого подхода?

Answer 1

Следуйте указаниям по присвоению имен, созданным Microsoft:

Имя, выбранное для пространства имен, должно указывать функциональность, предоставляемую типами в пространстве имен. Например, пространство имен System.Net.Sockets содержит типы, которые позволяют разработчикам использовать сокеты для связи по сетям.

Общий формат для имени пространства имен выглядит следующим образом:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

Например, Microsoft.WindowsMobile.DirectX.

Используйте префиксы имен пространств имен с названиями компаний, чтобы пространства имен разных компаний не имели одинаковых имен и префиксов.

http://msdn.microsoft.com/en-us/library/vstudio/ms229026(v=vs.100).aspx

В этом случае я бы сказал, что BusinessLogic или Dal являются просто абстракциями слоев и в действительности не принадлежат пространствам имен. Следовательно, я не буду использовать ни один из вас примеров, просто

Acme.EmailService

Эти дополнительные пространства имен только затрудняют поиск подходящего интерфейса / класса. Вы все равно используете несколько сборок, верно? В любом случае ваши разные слои будут разделены (с помощью сборок).

Спросите себя, что в действительности дает пространство имен слоя? Сколько классов в каждом пространстве имен? До 10? Делает ли это сложнее или проще работать с вашим кодом?

Answer 2

Во-первых, если у меня есть какой-либо библиотечный / общий код, он идет в пространстве имен, не относящемся к клиенту (здесь, CompanyName - это место, где я работаю):

CompanyName.DB
CompanyName.Common
CompanyName.Web

и т.д..

Во-вторых, если это зависит от клиента, я использую форму ClientName.Application.Functionality. Это потому, что если это не является распространенным явлением (и, следовательно, оно встречается в вышеупомянутых библиотеках и пространствах имен), я считаю, что функциональность принадлежит приложению, а не наоборот.

Просто мое мнение, очевидно;)

РЕДАКТИРОВАТЬ: Уточнение, я использую ClientName в качестве пространства имен верхнего уровня для конкретного клиента. У нас есть несколько проектов с некоторыми клиентами, и вы можете получить:

ClientName.Common
ClientName.Application1
ClientName.Application2

и т.д ...

Answer 3

Я считаю, что использование второго соглашения может испортить ситуацию, если у вас слишком много подслоев.Например, один из наших проектов содержит более 200 проектов, и я решил сгруппировать пространства имен по проектам, а не по функциональности, потому что функциональность принадлежит приложению, за исключением общих (действительно общих) функций.

Подумайте о Framework, мы могли бы использовать пространства имен, такие как System.Ui.Web, который содержит все связанные с UI подпространства имен вместо нашей текущей архитектуры, System.Web.Ui, которая группирует пространства имен по платформе / приложению.

Я не верю, что есть точная правда, я верю, что есть привычки, и очень трудно убедить людей изменить правила.