Папки или проекты в решении Visual Studio?

Когда при разделении решения на логические слои лучше использовать отдельный проект, а не группировку по папке?

Ответов (7)

Решение

По умолчанию всегда просто создавайте новую папку в одном проекте.

  • Вы получите разовую сборку (без дополнительной гимнастики ILMerge)
  • Легче запутать (потому что у вас будет меньше общедоступных типов и методов, в идеале вообще не будет)

Разделение исходного кода на несколько проектов имеет смысл только в том случае, если вы ...

  • Иметь некоторые части исходного кода, которые являются частью проекта, но не могут быть развернуты по умолчанию или вообще (модульные тесты, дополнительные плагины и т. Д.)
  • Вовлечено больше разработчиков, и вы хотите относиться к их работе как к расходному черному ящику. (не очень рекомендуется)
  • Если вы можете четко разделить свой проект на изолированные слои / модули и хотите убедиться, что они не могут перекрестно использовать внутренние элементы. (также не рекомендуется, потому что вам нужно будет решить, какой аспект является наиболее важным)

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

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

Я действительно считаю, что проект тоже лучше разделить, но все зависит от размера проекта и количества людей, работающих над ним.

Для более крупных проектов у меня есть проекты для

  • доступ к данным (модели)
  • Сервисы
  • внешний интерфейс
  • тесты

Я получил модель от Роба Коннери и его приложение для витрины ... похоже, действительно хорошо работает.

mvc-storefront

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

Но иногда разумно иметь разделение на основе сервисов (если вы используете сервис-ориентированную архитектуру), таких как аутентификация, продажи и т. Д.

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

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

Денни написал:

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

Я действительно согласен с этим - если вы можете использовать его повторно, это должно быть в отдельном проекте. С учетом сказанного, также очень сложно эффективно использовать повторно :)

Здесь, в SO, мы постарались быть очень простыми с тремя проектами:

  • Веб-проект MVC (который по умолчанию отлично справляется с разделением слоев на папки)
  • Проект базы данных для управления версиями нашей БД
  • Модульные тесты против моделей / контроллеров MVC

Я не могу говорить за всех, но я доволен тем, насколько просто мы его сохранили - действительно ускоряет сборку!

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

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

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

Почему это не рекомендуется? Я обнаружил, что это очень полезный способ управления приложением, когда несколько разработчиков работают над разными частями. Значительно упрощает проверку, в основном за счет практически полного исключения слияний. Очень редко двум разработчикам приходится работать над одним и тем же проектом одновременно.