Это лучше иметь больше количества DLL

Question

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

С уважением ArunDhaJ

Answer 1

Это распространенный, но хитрый вопрос. Лично мне не нравятся чрезмерно фрагментированные dll, так как это усложняет отслеживание и развертывание (IMO). Я предпочитаю ограниченное количество более длинных dll.

В дополнение к управлению проектами / dll это также уменьшает объем работы, выполняемой Fusion при загрузке.

Вы, очевидно, должны стремиться к повторно используемым компонентам, но просто не сходите с ума, делая их слишком гранулированные - рассмотрите, например, "System.Windows.Forms.dll"; там довольно много!

Вертикально, очевидные из них, которые следует разделять, - это проблемы пользовательского интерфейса / хранилища / логики; по горизонтали я склонен иметь один столбец dll на логическую область - но вы все равно можете разделить его на пространства имен , так что вам не нужно сохранять dll для просто одна вещь. 1013 *

Answer 2

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

Классы должны иметь свои собственные библиотеки DLL, поэтому, если вы чувствуете, что у вас довольно много классов, относящихся к определенным областям функциональности (например, DAL, BLL), то обычной практикой является перемещение их в свою собственную сборку.

Если у вас есть только несколько классов, которые, возможно, относятся к определенной области, вы можете просто разделить их, используя отдельное пространство имен (как предложил Марк).

Answer 3

Это лучший дизайн, чтобы иметь больше dll х? = Это лучший дизайн, чтобы иметь больше модули

Итак, если это зависит от логики вашего приложения, насколько оно велико, сколько логических «слоев» он использует.

Разделить эти уровни должен архитектор приложений (в конечном итоге вы).

конечно, лучше иметь больше маленьких функций, чем больших, но это правило не относится к прикладным модулям (проектам решений) ...

Answer 4

это зависит, но я бы сказал, да,

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

Answer 5

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

Но на практике, если количество dll не огромно (сотни), эти накладные расходы могут быть незначительными.

Многие библиотеки dll - это больше для установки (и обновления), а для разработки требуется больше проектов.

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

Answer 6

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

Answer 7

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

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

В общем, компоненты сборки, которые принадлежат друг другу, должны, конечно, оставаться вместе. Хороший пример Марка Гравелла для System.Windows.Forms.

Answer 8

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