Решения Visual Studio: у этих решений слишком много проектов?

В компании, в которой я сейчас работаю, мы поддерживаем 4 приложения Windows, которые в чем-то связаны. Для каждого приложения у нас есть решение, в каждом от 50 до 100 проектов. Вероятно, существует 40 или 50 проектов, которые используются одним или несколькими решениями.

Чтобы дать вам представление, более крупное решение включает почти 90 проектов, 20 из которых являются проектами пользовательского интерфейса (основное приложение, проекты настраиваемых элементов управления, помощник пользовательского интерфейса проектов), еще 20 - это проекты бизнес-уровня, вероятно, существует 30 или 40 проектов уровня доступа к данным, а остальные - это проекты служб Windows и специализированные проекты

. Мне всегда казалось, что в каждом решении слишком много проектов. Конечно, мы говорим о больших приложениях, но я не понимаю, почему многие проекты не могут быть объединены. В моей предыдущей компании у нас фактически был один проект для бизнес-уровня, один проект для DAL и, очевидно, по одному проекту для каждого окна или веб-приложения.

Вот некоторые из проблем, с которыми я столкнулся из-за большое количество проектов:

• Большое время компиляции.
• Классы, которые обычно должны быть закрытыми, должны быть общедоступными, чтобы быть доступными для других проектов на том же уровне.
• Недавно я начал использовать профилировщик Eqateq . Пробная версия позволяет профилировать до 10 dll. Моя ситуация, очевидно, усложняет использование этого приложения.
• Отслеживание ссылок между проектами довольно сложно. Я уверен, что между проектами есть много неиспользуемых ссылок.

Напротив, я не обнаружил преимущества этой ситуации.

Итак, мои вопросы:

• Когда вы решите создать новый проект вместо того, чтобы просто создать папку в текущем проекте?
• Есть ли какие-то преимущества, которые я упускаю из виду?

ОБНОВЛЕНИЕ:

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

ОБНОВЛЕНИЕ 2:

Все три ответа предоставили ценную информацию, но, поскольку я могу выбрать только один, я Выбираю Дока для его комментария о том, как определять количество проектов DAL. Я также ссылаюсь на другие вопросы, которые я только что нашел, которые содержат связанную информацию: Здесь и здесь . Я также рекомендую прочитать эту статью .