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

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

4.08.2008 22:00:41
7 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

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

18
4.08.2008 22:54:47
Мне нравится чувство реальности Любоса.
ybakos 18.05.2012 15:31:59
возможно, более старый ответ, но, о боже, я бы хотел, чтобы те консультанты, работающие в моей компании, имели такую ​​точку зрения. Я чувствую, что они всегда усложняют вещи заранее, как если бы они хотели доказать свою полезность, выплевывая вещи, которые они смогут поддерживать.
olleo 9.06.2019 15:07:40

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

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

8
17.08.2008 17:35:22
Когда я заменяю «теоретическое повторное использование» на «тестирование», остается ли ваше заключение верным?
reinierpost 11.06.2010 14:06:12

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

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

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

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

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

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

6
4.08.2008 22:42:55

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

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

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

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

4
4.08.2008 22:14:17

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

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

0
17.08.2008 17:19:51
Рекомендуется только для кода, который достаточно стабилен, чтобы можно было четко определить обязанности и интерфейсы для проектов.
reinierpost 11.06.2010 14:12:25

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

0
10.09.2008 21:36:06

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

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

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

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

MVC-витрина

0
27.01.2013 12:12:23