Является ли решение с сотнями проектов опасным или просто громоздким?

Question

Наше основное клиентское решение насчитывает 111 проектов.Когда я впервые начал работать в этой команде, я был удивлен (и встревожен) тем, что у нас было так много проектов, и рекомендовал объединить уровни в меньшие, но большие сборки.В нашей структуре есть модели (DTO) с файлами сопоставления nhibernate, а также уровень служб WCF с вызовами контроллеров данных, некоторые проекты с типом каркаса и CAB-приложение winform с несколькими модулями.мы будем использовать развертывание одним кликом.

из-за времени сборки (до 15 минут в худшем случае) некоторые другие члены команды теперь также обеспокоены.У меня нет эмпирических доказательств того, что меньшее количество проектов является хорошей идеей, и мне было интересно, есть ли у сообщества переполнения стека какие-либо отзывы.Существуют ли веские причины для изменения структуры нашего решения для консолидации проектов?Будем ли мы сталкиваться с проблемами при развертывании более 100 сборок с использованием однократного нажатия?Вызывает ли большее количество сборок медлительность при загрузке и вызове методов?Какие-нибудь ограничения, с которыми мы могли бы столкнуться, могли бы испортить вещи?

Answer 1

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

Запуск приложения может также пострадать, если нужно загрузить и инициализировать 100 сборок.Это, конечно, предполагает, что приложению нужны все 100 сборок.

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

Я бы не стал беспокоиться об истории развертывания, поскольку развертывание одной сборки в каталоге мало чем отличается от развертывания 100 в одном каталоге ... Конечно, развертывание 100 сборок через Интернет будет медленнее (100 соединенийвместо 1, вероятно, имеют больший размер ...).

Существуют инструменты, которые могут объединить несколько сборок, которые могут помочь с этим - самый известный из них от Microsoft - ILMerge .

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

Answer 2

Вполне возможно, что человек, выбравший для создания 110 проектов, может получить преимущества, используя 110 пространств имен в одной .dll.

Большое количество DLL делает это более очевидным, когда зависимости начинают ползти (1 dll ссылается на 22 других), но это также верно и для пространств имен (если у вас нет оператора using, тогда это препятствует внедрению ссылаться на множество других пространств имен.

Кроме того, когда вы объединяете сборки, вы теряете «внутренние» и, возможно, захотите сделать некоторые методы менее заметными, чем они были, что в любом случае хорошо.

Answer 3

In a gist: Развертывание будет наименьшим из ваших забот.

Реальные проблемы, с которыми вам придется столкнуться, помимо более продолжительного времени компиляции: >> возможная неэффективность сборки и снижение производительности разработчика.

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

1. На основе уровня зависимости вы можете выбрать наименее зависимые проекты.Например, если Project A имеет наименьшее количество оттока кода ... его стоит отделить ссылкой на автоматическую сборку ... в зависимости от используемого вами решения для сборки.

2. Кроме того, тривиальный совет: разработчики могут просто загружать проекты, над которыми они работают, для быстрого и эффективного запуска.

3. Если у вас есть настройка развертывания в нескольких средах, такая как: DEV,UAT, STAGE, MIRROR и PROD..переходный переход конфигурации каждый раз также будет королевской болью.Таким образом, вы можете перенести всю нетривиальную конфигурацию на уровень БД ... и сохранить чистые конфигурационные файлы ... используя их только для абсолютно необходимых объектов.

Answer 4

Не думаю, что возникнут какие-либо проблемы после того, как все будет скомпилировано и выполнено.

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