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

Question

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

Замедляет ли слишком большое количество сборок, есть ли критическая масса или "хорошее" количество сборок, которое должно иметь приложение? Аналогично, есть ли переломный момент, когда одна сборка слишком велика, и влияет ли большая сборка на производительность?

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

Спасибо!

---

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

Answer 1

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

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

Answer 2

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

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

Answer 3

Для меня основные причины, по которым я бы выделил некоторый код в dll:

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

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

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