Решение с сотнями проектов является опасным или просто громоздким?
наше основное клиентское решение имеет 111 проектов. Когда я сначала запустил в этой команде, я был удивлен (и предупрежден), что мы имели столько проектов и рекомендовали консолидировать уровни в меньше, но большие блоки. наша структура имеет модели (DTOs) с nhibernate отображающиеся файлы и сервисный уровень WCF с вызовами контроллера данных, некоторыми проектами типа платформы и winform приложение CAB с несколькими модулями. мы будем использовать щелчок однажды развертывание.
из-за времени изготовления (до 15 минут худший случай) некоторые другие члены команды теперь заинтересованы также. У меня нет эмпирического доказательства, что меньше проектов является хорошей идеей, и задавался вопросом, сообщество переполнения стека, имел любую обратную связь. Там неопровержимые доводы состоят в том, чтобы изменить нашу структуру решения для консолидации проектов? мы столкнемся с проблемой, имеющей 100 + блоки, развернутые с помощью щелчка однажды? Больше блоков вызывает замедление при загрузке и вызове вызовов метода? Какие-либо пределы, с которыми мы могли бы столкнуться, который мог повредить вещи?
4 ответа
Самая большая проблема, связанная с наличием множества проектов в одном решении (в частности, когда между проектами много взаимозависимостей), заключается в том, что время компиляции очень быстро замедляется. Я видел, как время компиляции составляло от нескольких минут до десятков минут, когда количество проектов становилось настолько большим.
Запуск приложения также может пострадать, если необходимо загрузить и инициализировать 100 сборок. Это, конечно, предполагает, что приложению необходимы все 100 сборок.
Такое большое количество проектов также намекает на проблемы организации кода. Я бы назвал это определенным запахом кода. Это похоже на попытку развязки, которая выходит за рамки разумного - немного архитектурного астронавтизма, на мой взгляд.
Я бы не стал беспокоиться об истории развертывания, поскольку развертывание одной сборки в каталог не сильно отличается от развертывания 100 сборок в один каталог ... Конечно, развертывание 100 сборок через Интернет будет медленнее (100 подключений вместо 1 , наверное, у них размер побольше ...).
Существуют инструменты, которые объединяют несколько сборок, которые могут помочь в этом - самый известный от Microsoft - ILMerge .
Более серьезная проблема, о которой следует беспокоиться при развертывании, - это конфигурация и правильная настройка, особенно если большинству сборок требуется собственная конфигурация.
Я не думаю, что когда все будет скомпилировано и готово, возникнут какие-либо проблемы.
При этом я знаю только из личного опыта, что множество проектов могут убить вашу эффективность. На моей машине (умеренной мощности) с множеством проектов в решении потребуется много времени, чтобы просто загрузить визуальную студию. Кроме того, когда на составление рабочего процесса уходит почти четверть часа, концентрация будет нарушена (тем более, если вы решите заняться чем-то другим, пока ждете).
Возможно, что преимущества, которые ищет человек, решивший создать 110 проектов, могут быть достигнуты с помощью 110 пространств имен в одной .dll.
Большое количество dll делает более очевидным, когда начинают проскальзывать зависимости (одна dll ссылается на 22 другие), но это также верно и для пространств имен (если у вас нет оператора using, то в нем встроено препятствие для ссылок на множество других пространств имен.
Кроме того, при слиянии сборок теряется "внутреннее", и, возможно, вам захочется сделать некоторые методы менее видимыми, чем они были, что в любом случае хорошо.
Вкратце: Развертывание было бы наименьшей из ваших проблем.
Реальные проблемы, с которыми вы могли бы столкнуться, помимо увеличения времени компиляции, следующие: >> вероятная неэффективность сборки и снижение производительности труда разработчиков.
В зависимости от типа автоматизированной настройки сборки ... сбой в дискретном наборе решений в одних и тех же проектах в сочетании с частыми проверками среди множества разработчиков ... обязательно даст вам (если еще не) серия кошмаров сбоя сборки.
Вот что вы можете сделать, чтобы смягчить:
В зависимости от уровня зависимости вы можете выделить наименее зависимые проекты. Например, если у проекта A наименьшее количество оттока кода ... его следует выделить с помощью автоматической ссылки на сборку ... в зависимости от используемого вами решения сборки.
Также тривиальный совет: разработчики могут просто загрузить проекты, над которыми они работают, для более быстрого и эффективного запуска.
Если у вас есть установка развертывания в нескольких средах, например: DEV, UAT, STAGE, MIRROR и PROD ... правильный перенос конфигурации каждый раз также будет настоящей головной болью. Итак, вы можете переместить всю нетривиальную конфигурацию на уровень БД ... и сохранить более чистые файлы конфигурации ... используя их только для абсолютно необходимых объектов.