Несколько DLL для одного уровня

Question

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

Я вижу разработчиков, разделяющих уровни на несколько DLL. Например, однажды я увидел уровень бизнес-логики с более чем ста различными файлами проекта и, следовательно, более ста разных DLL. Кроме того, документация MSDN показывает, что платформа .NET содержит несколько DLL, например. mscorlib и т. д.

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

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

Answer 1

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

Повторное использование кода похоже на фактор номер один для размещения кода в разных сборках. Например, у вас может быть консольное приложение, а весь код - это один исполняемый файл, который скомпилирован. Позже вы решили создать веб-приложение front-nd для того же приложения. Вместо того, чтобы копировать основной код из консольного приложения в ваше веб-приложение, вы, вероятно, реорганизовали решение в три проекта: библиотеку классов для кодового кода (основная реализация), консольное приложение (которое уже существует) и веб-приложение , Консольное приложение и проекты/сборки веб-приложений будут ссылаться на проект/сборку библиотеки классов, а основной код повторно используется для обеих реализаций. Имейте в виду, что это упрощение.

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

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

Answer 2

Какова причина разделения слоев на несколько DLL?

Для этого есть разные причины.

1. Он добавляет изоляцию, которая может помочь компилятору предотвратить смешение проблем. Не добавляя ссылку явно, вы не можете использовать внутренние типы в других DLL «случайно», что позволяет компилятору помочь вам очистить свой код.
2. Если вы не используете сборку во время выполнения, она не будет загружена. Это может уменьшить площадь памяти. (Однако, если все сборки используются, это не поможет).
3. Он обеспечивает логическое разделение внутри ваших API и проектов, что может помочь в организации и ремонтопригодности вашего кода. Обратите внимание, что слишком много проектов столь же плохи (а иногда и хуже), чем слишком мало, однако, поскольку многие проекты добавляют сложность, которая может оказаться нецелесообразной.