Должны ли внутренние приложения .NET размещаться в том же пространстве имен, что и внутренние библиотеки, от которых они зависят?

Question

Компания, в которой я работаю, недавно решила использовать комбинацию .NET и Java для всех будущих разработок. Мы пытались стандартизировать порядок организации нашего кода в пространствах имен (.NET) и пакетах (Java), и никто на самом деле не пытался организовать пространства имен для нескольких продуктов, использующих несколько платформ.

Недавно я связался с новым продуктом, в котором используется внешний интерфейс Java (он работает на устройствах Blackberry) с внутренним интерфейсом .NET (брокер сообщений, позволяющий интерфейсу Java взаимодействовать с нашим унаследованным кодом VB6 / COM, потому что мы Я не хотел иметь дело с COM на стороне Java, и было легко заставить работать .NET с нашим существующим кодом VB6). Прямо сейчас я просто фокусируюсь на стороне .NET.

Я создал новое решение .NET под названием CompanyName.ProductName.Broker и получил два подпроекта: проект библиотеки классов Core, который реализует большую часть кода брокера, и консольный проект BrokerConsole, который позволяет брокеру запуск и остановка из командной строки (брокер будет работать на сервере вместе с сервером очереди сообщений RabbitMQ).

В данный момент оба проекта находятся в подпространствах пространства имен CompanyName.ProductName.Broker. Вопрос в том, имеет ли это смысл?

С одной стороны, проект BrokerConsole довольно тесно связан с проектом Core, но, с другой стороны, BrokerConsole компилируется в автономный EXE-файл. Я подумал, что было бы более разумно поместить проект BrokerConsole в отдельное корневое пространство имен, возможно, что-то вроде CompanyName.Apps.ProductName, потому что это действительно интерфейс для CompanyName.ProductName.Broker.Core.dll и является приложением, а не библиотекой.

Мое обоснование для создания совершенно нового корневого пространства имен CompanyName.Apps заключается в том, что обычно при создании приложения вы помещаете его в отдельное пространство имен из библиотек, на которые ссылаетесь в любом случае (т. Е. Вы не будете помещать приложение веб-сервера в System.Web пространство имен). Я думаю в том же духе, за исключением того, что указанные библиотеки являются библиотеками, разработанными компанией.

Это хорошая идея, или я должен попытаться сохранить все, что связано с «продуктом» (в терминах маркетинга), в общем пространстве имен CompanyName.ProductName? Существуют ли более эффективные способы управления несколькими проектами, которые вместе составляют один продукт?

Answer 1

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

Итак, в принципе, я бы создал:

• CompanyName.ProductName.Broker.Core
• BrokerConsole

Answer 2

Обычно мы разделяем его так, чтобы у каждого проекта в решении было свое собственное пространство имен, в каждом проекте могут быть подпространства имен. Каждый проект и, следовательно, каждое пространство имен, следовательно, содержится в своей собственной dll.

Answer 3

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

Я думаю, что разница могла бы быть в этом, если бы я давал имена: сборка CompanyName.ProductName.Broker.Core, скорее всего, имела бы CompanyName.ProductName.Broker в качестве пространства имен "верхнего уровня" (исключая слово Core), тогда как консоль Приложение (которое я назвал бы CompanyName.ProductName.Broker.Console; пространство имен уже установило компонент Broker) будет иметь взаимно-однозначное отношение между именем сборки и именем пространства имен.

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

Answer 4

Я бы разделил их на CompanyName.ProductName.Broker.Console и CompanyName.ProductName.Broker.Core. Единственная потенциальная проблема с этим - использование Console в качестве имени, учитывая наличие System.Console. (Этого можно избежать, используя CompanyName.ProductName.Broker.BrokerConsole, но это немного уродливо.)

Разделение этих двух компонентов сделает их более понятными для будущих приложений, которые также могут захотеть использовать основные функции.

Answer 5

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

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

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

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

Например, у меня может быть пространство имен CompanyName.ProductName.Utility, которое обе сборки используют для организации кода утилиты, даже если оно не используется совместно между сборками.