Лучшая практика при создании корпоративного пространства имен многократного использования

Question

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

Пример: одиночная сборка (примеры пространства имен)

System

System.IO

System.IO.RegEx

System.Net

System.Net.Mail

System.Security

System.Web - AssemblyFull.dll

Пример: несколько сборок

System.IO

System.IO.Reg - Компилируется в AssemblyIO.dll

System.Net

System.Net - Компилируется в AssemblyNet.dll

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

Заранее спасибо.

Answer 1

Как правило, я использую для разделения сборок, если они не связаны явно. Например, если у вас есть Сетевой API низкого уровня и другие API для операций, связанных с FTP, вероятно, последний зависит от первого; но для пользователя API, ваших разработчиков; нет необходимости иметь оба в одной сборке; может быть, для одного проекта не требуется FTP API, поэтому им нужно только включить базовую «сетевую» сборку. Вы можете разделить API-интерфейсы, чтобы быть как можно более атомарными и избегать того, чтобы разработчики включали большую сборку, когда они будут использовать только небольшую ее часть.

Недостатком этого подхода является то, что если разработчик нуждается в сборке FTP, он также должен включить Net; поэтому вам нужно найти способ управления этими зависимостями, который снижает сложность для разработчиков. Я использую Maven (от Apache) при работе с Java-приложениями, но к этой дате я не знаю хорошей maven-подобной альтернативы для .NET .

Но если вы создаете несколько API-интерфейсов для своей компании, то с помощью сайта Wiki или другого легкого инструмента документации вы можете решить эту проблему.

Answer 2

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

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

Web.CreditCard
Web.CreditCard.Authorization
Web.CreditCard.Charge
Web.CreditCard.Batch

Web.Store.Order
Web.Store.Entities
Web.Store.Cart
Web.Store.Auth

Web.User.Auth.OpenID
Web.User.Auth.OAuth
Web.User.Account
Web.User.Preferences

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

Answer 3

Я использовал другой подход для многоразовых файлов.

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

Каждая повторно используемая «вещь» (класс, функция, UserControl,значок и т. д.) находится в отдельном файле.

Проекты, которым требуется некоторая функциональность из повторно используемой части, просто ссылаются непосредственно на исходный файл.(«Добавить существующий элемент», «Добавить как ссылку»).Для удобства я помещаю все повторно используемые детали в папку «утилит» в VS (папка реальных утилит пуста, так как файлы связаны)

Эта настройка позволяет мне:

• простодобавить необходимые мне общие функции
• без дополнительных зависимостей
• Исправления ошибок в утилитах автоматически включаются в следующую сборку

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

Поскольку я не использую разные сборки, пространство имен просто следует за функцией:

• Company.Utilites
• Company.Utilites.WPF
• Company.Utilites.IO

Answer 4

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

Первый:

Iнеобходимо определить, какие объекты бизнес / среднего уровня будут использоваться во всех проектах, продвигающихся вперед.Как только они будут определены, я создам сборку [компания] .common или [компания] .common.util .На них будут ссылаться для каждого из наших текущих и будущих проектов.

Секунда:

Идентифицируйте объекты, которые являются более специфичными для проекта.На эти сборки могут или не могут быть ссылки.Примером может быть [company] .security.cryptography .

Третий:

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

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