Как организовать большой проект с решениями / проектами / папками?

Question

Мы работаем над очень большим проектом VS.

Мы хотим, чтобы структура проекта «намекала» разработчиков на логические компоненты и дизайн.

Для этого лучше всего:

1. Один проект с множеством подпапок и пространств имен
2. Разделение на несколько проектов на основе логической группировки классов. Совместите все проекты в одном решении с папками решений.
3. То же, что # 2, но есть несколько решений вместо одного с подпапками.

Answer 1

Мои проекты огромны.

Мы разделяем каждый «модуль» на разные сборки, создавая библиотеки классов.Примерно так:

Client.ProjectName (Solution)
    Client (Class Library)
        - SectionHandler...
        - ComponentModels...
        - Utilities...

    Client.Web (Class Library)
        - Handelrs
        - Extenders

    Client.Net (Class Library)
        - MailQueue

    Client.Blog.WebControls.UI (Class Library)
        - TopContent.ascx
        - PostsList.ascx

    Client.News.WebControls.UI (Class Library)
        - TopContent.ascx
        - PostsList.ascx

    Client.Website

Каждый Class Library - это проект в рамках решения Client.ProjectName или в рамках другого общего решения.

Файловая система выглядит следующим образом:

Client
|- Framework
   |- Client
      |- files...
   |- Client.Web
      |- files...
   |- Client.Net
      |- files...
|- SolutionName
   |- Client.Blog.WebControls.UI
   |- Client.News.WebControls.UI
   |- Website

Совместно используемые клиентские библиотеки сразу попадают в папку Client\Framework, она предназначена для использования во всех проектах для этого клиента.Конкретные проекты идут под решение.У нас также есть папка Company, в которой мы храним проекты, которые можно использовать в любом другом проекте для любого клиента, это похоже на структуру компании.

Решения, которые мы используем:

• Один для структуры компании
• Один для структуры клиента
• Один для каждого решения клиента

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

С этим форматом мы могли бы использовать множество вещей в других проектах, просто ссылаясь на DLL.Без этой структуры некоторые проекты были бы невозможны в данное время.

Answer 2

Решения - это просто контейнеры для проектов, поэтому речь идет о разделении проектов.

Я бы рекомендовал использовать разные проекты (библиотеки классов или сборки AKA) для каждой основной функциональной области. Возможно, вы все же захотите использовать разные пространства имен в каждом проекте, но разделение основных функциональных областей на разные сборки сделает каждую сборку меньше. Поэтому, если вам нужно использовать только одну или две функции в приложении, вы ссылаетесь только на эти два проекта, а не на один массивный проект. Это будет полезно для небольших приложений, которые компилируются быстрее и имеют меньше накладных расходов.

С точки зрения решений, вы можете организовать те, которые вы хотите, потому что, как я сказал, они являются только контейнерами. Возможно, вы захотите объединить их все в одном решении ... или, может быть, каждый в отдельном решении ... или, возможно, включить связанные проекты в решения. Лично я использую либо одно решение, либо для больших проектов, я использую «мастерское» решение, чтобы я мог легко собрать все за один раз и отдельные решения, чтобы я мог работать над проектами индивидуально.

Answer 3

Проект должен быть вашим «атомом» повторного использования.Или, другими словами, проекты - это гранулярность многократно используемого кода.Можно иметь взаимозависимые проекты, но каждый проект должен планироваться таким образом, чтобы он был полезен для своей собственной функциональности.

Решение - это просто любая коллекция проектов, необходимая для разработки / сборки / тестирования.У вас может быть несколько решений, которые определяют разные подмножества проектов.

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

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

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

Answer 4

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

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