Рекомендации по пространству имен и именам классов

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

Как бы вы структурировали следующее:

EventService.cs
EventServiceUtils.cs
EventServiceValidators.cs
EventServiceCoordinator.cs

и т.д...

У меня есть несколько служб с теми же потребностями, что и вышеупомянутая служба. Одна мысль состоит в том, чтобы разделить все это в подходящее пространство имен, чтобы оно выглядело примерно так:

Services.EventService.EventService.cs //(the actual service)
Services.EventService.Validators.DateValidator.cs
Services.EventService.Validators.ParticipantValidator.cs
Services.EventService.Coordinators.ParticipantCoordinator.cs
Services.EventService.ExtensionMethods.Extensions.cs

и так далее. Каждое пространство имен - это, конечно, отдельная папка. Но это не чувствуется на 100%, так как DateValidatorsв других сервисах, вероятно, их больше , что может легко привести к нежелательной ссылке.

А также Services.EventService.EventService.csвключает в себя имя класса в пространстве имен, что тоже не годится. Вы можете использовать Services.Event.EventService.cs, но, конечно, уже существует сущность с таким именем.

Это модель предметной области.

Я думаю, что самое большое, что вы можете сделать для улучшения своего пространства имен - это удалить Serviceиз своего EventServiceпространства имен. Я также настроил бы пространства имен так, чтобы они были такими:

Services.Events.EventService.cs //(the actual service)
Services.Events.EventExtensions.cs
Services.Events.ParticipantCoordinator.cs
Services.Validators.DateValidator.cs
Services.Validators.ParticipantValidator.cs

Я все еще думаю, что это может использовать некоторое улучшение, хотя.

Раньше мне нравились пространства имен, но сейчас я думаю, что меньше значит больше. Глубокое вложение ваших пространств имен может сделать ваш код слишком многословным, а разбивка на части значительно снижает вашу способность к наследованию. Например, в вашем коде DateValidatorкласс можно легко использовать в другом месте, поэтому над ним не должно быть много пространств имен, поскольку службы, отличные от EventService, теперь могут использовать класс DateValidator. То же самое относится и к методам расширения. Нет времени (которое я вижу), когда вам нужно было бы видеть все ваши методы расширения одновременно, поэтому имеет смысл сгруппировать его с тем, к чему он относится. В этом случае, EventExtensionsвероятно, ссылки на ваши EventService, поэтому по логике они должны сидеть вместе на мой взгляд.

Почему вы не читали Общие Правила именования и пространство имен Именования Руководства от Microsoft следовать универсальному шаблону?

Я думаю, что формула <Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]просто отлично работает.

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

Хотя первоначальное обоснование для пространств имен было главным образом для предотвращения конфликтов имен между именами объектов и методов, оно стало важным элементом общей архитектуры и дизайна решения. Вы не только хотите, чтобы ваша концептуальная иерархия и логический дизайн имели смысл, вы, вероятно, также хотите, чтобы ваш код был аккуратно упакован в хорошо спроектированные и легко повторно используемые библиотеки, которые впоследствии могут быть легко включены в другие проекты и продукты. Это, пожалуй, более желаемый результат хорошего физического дизайна.

Посмотрите на .NET Framework и на то, как вам предоставляются блоки соответствующей функциональности в сборках разумного размера. Вы можете добавить ссылку и оператор использования, и вдруг у вас появятся соответствующие функциональные возможности без необходимости перетаскивать любое количество кухонных раковин. Это связано с тем, что физический дизайн .NET Framework, включая интеллектуальное пространство имен, содержит логически связанный код в физически связанных развертываемых единицах. Создавая превосходное отображение между пространствами имен и сборками, архитекторы и разработчики .NET Framework Microsoft значительно упростили вашу работу (конечно, некоторые могут поспорить иначе, но я довольно доволен тем, что они сделали).

Пространство имен в C # довольно произвольно. Вы можете поместить пространства имен в самые странные места, в сборки, расположенные далеко друг от друга. Любая полезная дисциплина в этой области - это ваш личный вклад в хорошо организованный программный продукт. Я бы не посмел посоветовать вам, что конкретно делать в каждом конкретном случае. В этом ответе я надеюсь добиться того, чтобы вы подумали о физическом дизайне, а также о логическом дизайне при определении своих пространств имен. Чем больше вы держите вещи логически связанными и связываемыми (физически) связанными, тем проще это будет позже, как для вас, так и для других, которым, возможно, придется когда-нибудь разобраться с вашим кодом.

Поэтому, пожалуйста, подумайте о том, как ваш код будет упакован в сборки и компоненты, когда вы решите проблемы с пространством имен!