Правильная структура .NET DLL для приложения

Question

... если есть такая вещь. Вот изображение двух подходов для структурирования DLL / ссылок в приложении .NET: http://www.experts -exchange.com / images / t80668 / compArch.png . Приложение может быть веб-сайтом (это в данном случае) или winform. Каждый блок представляет собой DLL. Для приложения winform просто замените «webcontrols» на «winformcomponents».

Первое (верхнее) изображение - это то, что мне нравится. Возможно, вы захотите расширить «некоторые» из базовых веб-элементов управления и напрямую использовать другие. Второе изображение заставляет вас расширять любые веб-элементы управления через интерфейс. Мне это кажется излишним, поскольку вы можете просто использовать то, что уже есть, без изменений. Что лучше и каковы преимущества / недостатки?

Первое изображение помещает самые распространенные общие конструкции (исключения, fileIO, константы и т. Д.) В common.dll. Второе изображение объединяет бизнес-логику приложения и общую в одну DLL. Что лучше и каковы преимущества / недостатки каждого приложения?

Answer 1

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

Answer 2

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

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

Лично я склонен следовать тем же принципам, что и структура MS, по следующим причинам:

• Для новичков в пользовательской «структуре» легче найти то, что они хотят (например, CompName.Web.UI и CompName.Data.
• Это помогает уменьшить зависимости до «очевидного» выбора. Я не слишком заинтересован в DLL-библиотеках типа CompName.Common, поскольку в них не указаны четкие возможные зависимости, в то время как CompName.Web.UI предполагает, что она, вероятно, будет использоваться любыми веб-приложениями.
• Очевидное уменьшение размера, поскольку содержимое DLL будет более "релевантным".

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