Какое оптимальное количество проектов в решении Visual Studio 2008?

Какое оптимальное количество проектов в решении Visual Studio 2008?

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

Если кажется, что в одном решении «слишком много проектов», то как вы подойдете к определению, какие проекты следует сгруппировать в одно решение? Учитывая наш пример, состоящий из примерно 50 проектов в одном решении, при этом основная часть проектов является подключаемыми модулями, а количество подключаемых модулей, вероятно, будет расти, как следует структурировать решения? Следует ли размещать все плагины в отдельном решении? Как должна измениться организация, если количество подключаемых модулей в решении для подключаемых модулей достигает магического числа «слишком много»?

У нас нет проблем с таким количеством проектов в решении ... оно быстро загружается, быстро строится, использует разумный объем памяти и не вызывает сбоев VS2008 или столкновения с какими-либо ошибками VS2008.

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

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


6
1 355
4

Ответы:

Я бы сказал, что вам нужен как минимум 1 проект для каждого слоя в вашей системе. Если вам нужно больше проектов, возможно, это проблема дизайна. Это означает, что вы можете разработать приложение либо «сверху», либо «под».

Сейчас я использую следующие слои:

DataLayer - отвечает за базовую структуру данных (базу данных). В последних случаях наличие LINQ и частичных классов для этого в этом проекте.

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

Логика - это определяет себя, бизнес-логика

GUI / Front - графический интерфейс пользователя (код)

Эти слои - это минимум других слоев, которые МОГУТ быть возможными, это локализация и другие проекты, которые могут расти.

Но лучше упростить каталоги и пространства имен, чем использовать для многих проектов!


Очевидно, когда вы доходите до 500, вы начинаете смотреть на «слишком много», и даже управлять им становится непрактично.

Я мог бы предложить вам проанализировать, «что на самом деле составляет мое приложение», и упаковать это как единое решение. Плагины редко считаются частью базового приложения, но являются дополнениями к базовой функциональности.

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

Другие плагины могут быть сгруппированы по жанрам ... так же, как списки воспроизведения на вашем iPod. Что дает каждый плагин на более общем уровне? (Это, очевидно, риторические вопросы). Я бы сгруппировал плагины в естественные группы - так же, как плагины PhotoShop, поскольку они группируются в меню. то есть влияют ли они на 3D, влияют ли они на цвет, влияют ли они на геометрические эффекты, влияют ли они на искажения и т. д.


Решено

Это похоже на дискуссии типа "сколько функций я должен иметь в классе?" и «следует ли определять каждое перечисление в собственном CS-файле?».

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

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

Тем не менее, это звучит как довольно большое число, но тогда мы ничего не знаем о размере вашей общей кодовой базы, поэтому трудно комментировать дальше.


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

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