Что лучше, много мелких сборок или одна большая сборка?

Все в заголовке:)

В настоящее время у нас есть решение VS2005 с 20+ проектами. Как

MySolution
MySolution.Modules.Foo
MySolution.Modules.Bar
[insert many here]
MySolution.Modules.Baz

Может ли быть вред для "слияния" MySolution.Modules. * в одном проекте? Все пространства имен будут сохранены, поэтому здесь нет проблем.

Но есть ли что-нибудь, о чем я не думал?

Примечание. В настоящее время не может быть круговых ссылок: если MySolution.Modules.Foo ссылается на MySolution.Modules.Bar, MySolution.Modules.Bar не может ссылаться на MySolution.Modules.Foo. Поэтому мы должны быть осторожны, чтобы не создавать.

Ответы

Ответ 1

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

Подумайте о проекте как о единице повторного использования, среди прочего. Будет ли какой-нибудь продукт нуждаться в Foo, но не в баре, или наоборот? Если нет, объедините их вместе.

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

О, и, конечно же, держите тесты в другом проекте с вашим производственным кодом:)

Ответ 2

Преимущества одной сборки:

  • потенциально перформативный
  • потенциально простое развертывание

Преимущества многих сборок:

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

Ответ 3

Мы используем ILMerge, чтобы связать все наши маленькие сборки с большим блоком. Особенно сборки, которые находятся в разных проектах, но в конечном итоге являются частью пространства имен.

Например, у нас есть много объектов данных для записей и представлений, распространенных по нескольким ассамблеям, MJ.DE.views.dll, MJ.DE.tables.dll, MJ.DE.sprocs.dll и т.д., но в в конце мы используем ILMerge, чтобы связать их вместе в один MJ.DE.DLL. - упрощает обновление/синхронизацию приложения, так как на производственном сервере меньше скриптов piecesto, и мы знаем, что все связанные классы связаны с одним и тем же компилятором.

Ответ 4

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

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

Ответ 5

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