Что лучше, много маленьких сборок или одна большая сборка? - PullRequest
13 голосов
/ 20 февраля 2009

Все в названии:)

В настоящее время у нас есть решение 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. Поэтому мы должны быть осторожны, чтобы не создавать их.

Ответы [ 5 ]

14 голосов
/ 20 февраля 2009

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

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

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

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

11 голосов
/ 20 февраля 2009

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

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

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

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

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

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

3 голосов
/ 20 февраля 2009

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

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

3 голосов
/ 20 февраля 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...