.NET - много проектов и один проект

В настоящее время мы имеем быстро растущую кодовую базу С#. В настоящее время у нас есть около 10 проектов, разделенных по обычным категориям, общим/обычным вещам, сетевому уровню, базе данных, компонентам/элементам управления ui и т.д.

Мы сталкиваемся с случайной циклической зависимостью, когда проект x зависит от чего-то в y и наоборот. Мы смотрим, возможно, сворачиваем проекты до одного и просто управляем использованием структурных папок/пространств имен. У нас есть проект Java, который, естественно, организует только использование папок/пакетов, поэтому мы не уверены, что, если таковые имеются, принесут много проектов. Ни один из наших проектов не требует специальных свойств проекта, кроме основного проекта проекта, который мы можем сохранить отдельно (и очень тонким).

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

Любой вход оценивается.

Ответ 1

По моему опыту, разделение кода, создающего исполняемый файл single в проектах multiple, может быть полезным, если вы хотите

используйте разные языки программирования в разных частях,
создавать библиотеки, которые также используются другими приложениями, или
концептуально разделять несколько уровней (то есть позволить Visual Studio гарантировать, что нет прямых ссылок из проекта Lib для проекта App).

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

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

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

Ответ 2

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

Ответ 3

При создании зависимостей между проектами это помогает всегда думать об одном как "Нижнее", а другое как "Высшее"

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

Ответ 4

Вообще говоря, наличие нескольких VS-проектов (в рамках VS-решения) имеет смысл в этих случаях

Вы можете повторно использовать произведенную DLL в другом проекте (библиотеке классов)
Вы хотите разделить такие вещи, как в многоуровневой архитектуре, где вы можете сбросить DAO-dll и обменять ее с другим
Существуют только разные интерфейсные проекты (например, приложения ASP.net MVC), которые необходимо развернуть в разных физических местах, но использовать те же BL, DAL.

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

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

Ответ 5

Мы заметили, что производительность Visual Studio значительно ухудшается по мере роста числа проектов. Что-то простое, как переход с конфигураций "Отладка" в "Релиз", может занимать до 15 секунд для решений с примерно дюжиной проектов С# в них.

Кроме того, в качестве контрольной точки для комментариев Рида о временах сборки, я видел, что времена сборки растут, потому что Visual Studio, похоже, тратит много времени на накладные расходы проекта. Фактические времена компиляции кажутся быстрыми, но значительное время от удара по сборке до возможности выполнить значительно.

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

Ответ 6

Существует несколько причин для разделения решения на разные проекты (и, следовательно, сборки), и в основном это сводится к re-usabilit y и разделению обязанностей.

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

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

Примечание. Однако:

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

Ответ 7

Вы можете найти следующую статью Мартина: Принципы проектирования и шаблоны проектирования (PDF) (Java).

Пересмотренная версия на С# специально доступна в Agile Principles, Patterns и Practices в С# также Мартином.

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

Ответ 8

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

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

Ответ 9

Где я работаю, мы выбрали подход, в котором цель состоит в том, чтобы иметь один проект на одно решение. Все проекты библиотеки кода также имеют приложение для тестирования и/или приложение unit test.

Пока библиотеки кода проходят тестирование, версии выпуска (с файлом документации Xml, конечно) передаются в папку "Live".

Любые проекты, требующие функциональности из этих других проектов, должны ссылаться на них из папки "Live".

Преимущества довольно ясны. Любой проект всегда обращается к известному рабочему коду. Никогда не будет возможности ссылаться на работу в процессе сборки. Код тестируется на сборку, что значительно облегчает понимание места возникновения ошибки. Менее простые решения упрощаются.

Надеюсь, это поможет!

Шад

Ответ 10

Начните с одного проекта. Единственное преимущество в разделении вашей кодовой базы на большее количество проектов - просто улучшить время сборки.

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