Что лучше, много маленьких сборок или одна большая сборка?
Все в названии:)
В настоящее время у нас есть решение 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 ответов
Я был в нескольких компаниях, где слишком много проектов было болью по-разному. Я еще не был нигде, где было бы слишком мало проектов, хотя это, безусловно, возможно.
Подумайте о проекте как о единице повторного использования, помимо прочего. Любой продукт будет нуждаться в Foo, но не в Bar, или наоборот? Если нет, объедините их вместе.
Мне нравится разделять разные слои (презентация, бизнес-логика, доступ к данным), и приятно иметь общую библиотеку утилит, не зависящую от продукта, но во многих случаях об этом.
Да, и держите тесты в проекте, отличном от вашего производственного кода, конечно:)
Преимущества одной сборки:
- потенциально перф
- потенциально более простое развертывание
Преимущества многих сборок:
- Все остальное Предполагая, что это хорошие связные модули, это помогает разделить проблемы, контролирует зависимости, заставляя задуматься о выравнивании / расслоении вашей архитектуры и т. Д.
Мы используем ILMerge, чтобы связать все наши маленькие сборки в более крупный блок. Особенно сборки, которые находятся в разных проектах, но в конечном итоге являются частью одного пространства имен.
Например, у нас есть много объектов данных для записей и представлений, распределенных по ряду сборок, MJ.DE.views.dll, MJ.DE.tables.dll, MJ.DE.sprocs.dll и т. Д., Но в конце мы используйте ILMerge, чтобы связать их вместе в одну MJ.DE.DLL. - упрощает обновление / синхронизацию приложения, поскольку на рабочем сервере меньше кусков, которые можно использовать, и мы знаем, что все связанные классы происходят из одной и той же компиляции.
Во-первых, Visual Studio начинает загружать ваше решение дольше и дольше, если у вас есть тонны проектов, в отличие от нескольких проектов с тоннами кода в них.
Это не обязательно является достаточно веской причиной, чтобы иметь один проект, помимо всех других, упомянутых здесь, но что-то нужно иметь в виду.
Время компиляции. Если ваш проект разбит на части, необходимо скомпилировать только измененную часть. Если это все часть одного большого проекта, вам придется все перекомпилировать каждый раз, когда вы что-то меняете. В зависимости от того, насколько велик ваш проект, это может иметь большое значение.