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

15

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

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

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, но, конечно, уже существует сущность с таким именем.

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

c# architecture Маттиас
источник
«У меня есть несколько сервисов с такими же потребностями, как и у вышеуказанного сервиса». Означает ли это, что несколько сервисов используют приведенный выше код, или что несколько сервисов должны предоставлять свою собственную версию по одному и тому же шаблону?
Натанаэль
То, что они предоставляют свою собственную версию того же шаблона
Маттиас

Ответы:

5

Я думаю, что самое большое, что вы можете сделать для улучшения своего пространства имен - это удалить 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, поэтому по логике они должны сидеть вместе на мой взгляд.

Карл Николл
источник
Проект слишком велик, чтобы не сломать его до определенного уровня. DateValidator в пространстве имен событий обрабатывает только конкретные события и поэтому не может использоваться в другом месте. Мне нравятся Услуги. События .EventService. Как я мог не думать об этом. Я думаю, пришло время для некоторого рефакторинга!
Маттиас
@ Mattias - это честно. Насколько я могу видеть, пространство имен (помимо основных принципов, таких как те, что упомянуты Саидом ниже) в значительной степени просто вопрос вкуса.
Карл Николл
2

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

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

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

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

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

Джон Тоблер
источник