Являются ли приложения со многими DLL файлами плохими?

У нас есть веб-приложение enterpise, состоящее из 4 скомпилированных компонентов (DLL). Более года назад мы начали внедрять более гранулированные компоненты, пытаясь изолировать функциональность, уменьшить сцепление и снизить риск перекомпиляции и развертывания массивных кусков кода. В то время как никто не утверждает, что этот подход дал нам БОЛЬШУЮ повышенную гибкость и скорость выхода на рынок при добавлении новых функций и исправлении ошибок, теперь приложения составляют около 40 библиотек DLL. У нас есть соглашение об именах, которое хорошо работает для идентификации наших компонентов.

Мой вопрос: есть ли какая-либо нижняя сторона (производительность, обслуживание и т.д.) для приложения со многими DLL?

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

Ответ 1

Мой вопрос: есть ли вниз (производительность, обслуживание, и т.д.), чтобы иметь приложение с много dll?

Недостатком многих DLL? Нет
Недостаток слишком большого количества DLL? Конечно.

Так сколько же слишком много?

Сборка - это средство организации, такое как пространства имен и классы. Пространства имен определяют логические границы, собирают физические границы.

Вы должны попытаться сохранить связности согласованными и просмотреть их как системные модули.

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

Ответ 2

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

Однако есть недостатки для введения нескольких сборок в составе системы:

Требуется больше времени для загрузки, проверки и JIT нескольких сборок.. Это редко бывает проблемой, и, как правило, ваша основная задача не связана с решением о разделении функциональности приложения.
Неправильно обновлять приложение, развертывая изменения внутри одной сборки.. Часто разделение приложения на отдельные библиотеки DLL создает впечатление, что его можно исправить или усовершенствовать, заменив только некоторые из них сборок. Хотя это, безусловно, возможно, это может ввести тонкие ошибки, если есть изменения в побочных эффектах или недокументированном поведении классов и методов в этих сборках.
Может быть сложнее понять систему, которая разделена на слишком много сборок. У инструментов, таких как ReSharper и CodeRush, есть некоторые ограничения при анализе кода, разделенного на несколько сборок.
Он может поощрять разработчиков делать больше типов общедоступными, чем они должны.. Поскольку только общедоступные типы могут быть использованы и унаследованы другими сборками, проект с несколькими сборками может привести к большему количеству публичных типов, чем может быть желательно.

Ответ 3

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

Ответ 4

Типы проблем, которые ухудшаются с большим количеством DLL, следующие:

Время сборки: компилятор запускается один раз для каждой DLL, а библиотеки DLL должны быть скопированы в каталог вывода из каталога
Время загрузки: каждый DLL файл должен быть загружен отдельно Windows, хотя для загрузки требуются DLL, поэтому вы обычно несете затраты только на те части, которые вы используете.
Rebasing: чем больше DLL файлов у вас есть, тем больше вероятность столкновения двух виртуальной памяти. Это не создает проблем, поскольку Windows может переустановить один из них, но процесс восстановления требует времени, и Windows должна заранее загружать любые затронутые DLL-страницы с диска. Rebasing обычно не влияет на управляемые DLL.
Накладные расходы Visual Studio: одна DLL = один проект = больше работы для IDE

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

Ответ 5

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

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