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

Question

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

денис писал:

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

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

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

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

• доступа к данным (модели)
• услуги
• передний конец
• тесты

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

mvc-storefront