Большинство проектов в одном решении

Question

для VS 2005 - максимальное количество проектов, которые могут вызвать проблемы с производительностью. У нас сейчас до 25 проектов и растут. Должны ли мы делать эти двоичные ссылки или мы разбиваем логику нашего приложения на слишком много разных проектов. Похоже, в последнее время это стало большой проблемой производительности.

Answer 1

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

Взгляните на эту статью: Анти-шаблон проекта: многие проекты в файле решения Visual Studio .

Answer 2

Обычно мы стараемся поддерживать количество проектов в рамках решения меньше 10. После 10 у вас начинается медленное время компиляции и медленное время «перезагрузки проекта».

Но главная проблема здесь в том, почему у вас 26 проектов? На простом веб-сайте может быть только 1 проект, при этом все уровни данных, бизнес-уровня и уровня презентации находятся внутри одного проекта.

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

Итак, в целом, держите проекты под 10 и проверяйте, можете ли вы объединить некоторые проекты вместе. Это сэкономит вам время во время компиляции и во время сборки. Также будет проще управлять этими DLL.

Answer 3

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

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

Используйте «запуск без отладки», если вы не планируете достичь точки останова.

Являются ли некоторые библиотеки DLL стабильными и не менялись в течение длительного времени? Они также не должны быть в вашем решении.

Не ищите решения целиком, если вам действительно не нужно.

Настоящее ограничение - человеческий разум. Сколько файлов в одном проекте можно обрабатывать? Кроме того, если вы не используете ndepends для отслеживания зависимостей, добавление нескольких классов в один проект может привести к слишком большому количеству классов в зависимости от других классов, что делает изменения более трудными и рискованными.

Answer 4

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