Отдельные проекты или несколько файлов классов ... лучшие практики пространства имен в C #

Question

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

MyNamespace.Validation
MyNamespace.Reports
MyNamespace.Transactions
MyNamespace.DataImport
etc...

Будет ли оптимальной практикой создание решения с несколькими проектами для каждого подпространства имен или одним проектом с несколькими файлами классов для каждого подпространства имен? Спасибо.

Answer 1

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

Pro для нескольких проектов:

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

Минусы для нескольких проектов:

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

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

Answer 2

Точное решение о том, как разбить ваше решение, субъективно - и оно действительно зависит от специфики вашего кода.

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

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

Answer 3

Я бы сказал, это зависит.

• Во-первых, рекомендуется помещать каждый класс в отдельный файл.
• Если вы идете с одним проектом, я бы создал папки для каждого пространства имен внутри этого проекта и поместил файлы кода в соответствующую папку.
• При выполнении вышеизложенного Visual Studio автоматически создает новые файлы классов в правильном пространстве имен

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

Если это когда-либо будет использоваться только один раз, то все в одном проекте имело бы смысл. Однако, если этот код будет многократно использоваться, вам следует подумать, если бы вы когда-нибудь повторно использовали только часть (или одно подпространство имен) этой библиотеки. Если ответ «да», я бы разделил пространства имен на отдельные проекты, поэтому в будущем вы можете включать только те проекты, которые вам нужны.

Answer 4

Я бы выбрал одно решение с несколькими проектами.

Преимущества:
- Каждый проект может быть отдельной DLL
- Все проекты в одном решении для удобной навигации между файлами

Answer 5

Я обычно следовал шаблону с одной сборкой в ​​одном пространстве имен, а имя DLL в пространстве имен. Проще найти, на какие DLL ссылаться