В .NET (Visual Studio), когда вы создаете новую сборку?

Я работаю над приложением Silverlight. Я разделил его на несколько сборок:

Домен
Репозитории (все с сохранением в базе данных Sterling)
UI
...

Вот как я это узнал, но мне было интересно. Если вы знаете, что библиотеки DLL не будут использоваться повторно, нужно ли их разделять? Или вы могли бы поместить все в одну сборку и использовать папки и пространства имен, чтобы поддерживать порядок?

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

Итак: когда вы создаете новую сборку для какого-то нового куска кода? Есть хорошие ресурсы на эту тему? И разделяете ли вы код на технически (домен, данные, пользовательский интерфейс и т. Д.) И / или функционально (т. Е. Администрирование пациента, медицинское обслуживание пациента, логистику больницы, ... - возможно, только для более крупных приложений уровня предприятия)?

— Питер
источник

Ответы:

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

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

Конечно, вы не должны преувеличивать, но отделяйте, где это уместно. Подумайте об этом так: «Эти классы принадлежат друг другу и им не нужно знать об этих классах» и разделяйте их

— Homde
источник

Зависит от того, что вы подразумеваете под «модулями», но я обычно делю связанную логику, используя пространства имен, а не сборки. Помните, что пространства имен могут охватывать сборки. Сборки - это единица развертывания, поэтому вам следует рассмотреть возможность сборки сборок в соответствии со сценарием развертывания.

— Эд Джеймс

Не хорошая идея. VS становится очень вялым, когда решение содержит более нескольких проектов.

— nikie

Если ваш VS становится слишком вялым, вы используете старую версию или медленный компьютер. У меня есть огромные проекты с более чем 30 проектами, которые компилируются за считанные секунды. С другой стороны, у меня много оперативной памяти, ядер и твердотельного накопителя :) Конечно, не следует преувеличивать, а только разделять, где это уместно, думать об этом примерно так: «Эти классы принадлежат друг другу и им не нужно знать об этих классах» и отдельно по этим направлениям

— Homde

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

— Питер

При таком подходе вы могли бы в конечном итоге с кучей сборок: A, B, C, D, E, F, G, H, I, J, K. Где бы вы ни ссылки на узел A, вы должны также ссылаться на зависимые сборки: B, C, D. Но сборка Cзависит от: E, F, G, Hпоэтому мы будем нуждаться в тех , кто тоже. Поэтому, когда вам нужна какая-то функция, Aвам нужно снять 7 дополнительных сборок, чтобы она заработала; убедившись, что вы получите правильные версии каждой сборки. Добро пожаловать в новый DLL Hell.

— Эд Джеймс

Сборка - это единица развертывания приложения .NET; поэтому вы должны рассмотреть возможность согласования разреза ваших сборок с архитектурой развертывания.

Сборки также полезны, когда вам нужен отдельный контроль версий для некоторого кода. Например, если у вас есть общие интерфейсы, которые выиграют от независимого контроля версий, вы должны разделить этот код на сборку.

Помните, что пространства имен могут охватывать сборки. Во многих случаях достаточно разделить поведение, используя пространства имен. Посмотрите на .NET, mscorlib.dllкоторый в одной сборке содержит код, охватывающий широкий спектр поведений, разделенных только пространством имен.

Если вы хотите авторитет в этом вопросе, смотрите не дальше:

Руководство по проектированию рамок

Руководство по разработке структуры: условные обозначения , идиомы и шаблоны для многократно используемых библиотек .NET (2-е издание). Автор - Кшиштоф Квалина и Брэд Абрамс.

— Эд Джеймс
источник

Спасибо за ссылку на книгу действительно. Я проверю это. Не могли бы вы подробнее рассказать об архитектуре развертывания? Чем развертывание 10 DLL-файлов отличается от развертывания 1? Разве вы не можете обновить один из десяти файлов, в то время как остальные остаются нетронутыми?

— Питер

@Peter: если вы закодировали 10 сборок, которые всегда развертываются вместе, то вы могли бы упростить управление версиями и развертывание, поместив весь код в одну сборку. Если 10 сборок не всегда развертываются вместе, то полезно иметь отдельные сборки.

— Эд Джеймс