Как вы решаете, какие сборки должны разбивать ваш проект?

Question

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

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

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

Спасибо!

---

(Хотя в моем конкретном случае, если кто-то хочет, чтобы комментировать, я строю службы WCF с бизнесом и DAL слоем под и веб-сайт, чтобы потреблять услугу. Я традиционно создал множество небольших сборок, но теперь я думаю о простоте «Web», «Service», «Model» и, возможно, «Data» (для репозиториев и т. д.) выглядит довольно привлекательно. Ссылки на веб-сайты Только сервис, ссылки на службы Только модель, .. и модель ссылается на данные только не уверен, насколько это важно)

Answer 1

Я склонен идти за одним/слоем, который является вертикальным сплитом, как только база кода начинает расти. Затем я смотрю на разделение по горизонтали, обычно ориентируясь на определенные части бизнес-функций. Например, если мой уровень сопротивления говорит с> 20 или около того таблицами, я бы хотел разбить это, зная, где разделение - это немного черное искусство, это очень специфичный домен и проект.

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

Answer 2

на мой взгляд, основные причины, почему я изолируют код в DLL являются:

• обмен Функциональности между несколькими проектами
• Простой поставкой новых версий этой функции без обновления другого обмена
• интерфейса между клиентом и сервером, например

Если вам нужны один из тех вещей, вам следует рассмотреть вопрос о внесении DLL

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

Answer 3

Кажется разумным для меня один для каждого слоя, один для любых «сверху донизу» приложений, специфичных для приложения (например, модель) и один для «обычных утилит». Одно из преимуществ разделения между слоями заключается в том, что тогда типы и методы internal и т. Д. Будут видны только в их слое, что может быть хорошим помощником для инкапсуляции.

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