Структуризация проектов и решений для управления исходным кодом

Обзор

В этой лекции рассматриваются различные возможности структурирования файлов решений и проектов Visual Studio для командной разработки. Файлы решений (.sln) используются в Visual Studio для группирования файлов взаимосвязанных проектов Visual Studio (.csproj и .vbproj) . От выбора модели структурирования проектов и решений зависит многое, например, насколько легко члены групп разработчиков смогут записывать решения и проекты в базу управления исходным кодом и извлекать их из нее.

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

Стратегии структурирования решения и проекта

Для структурирования файлов решений и проектов чаще всего используются три стратегии:

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

В целом, следует придерживаться следующих рекомендаций:

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

Разрабатывая структуру проекта и решения, учитывайте следующие моменты:

• Каждый проект во время сборки генерирует файл сборки (assembly) . Для начала определите, какие файлы сборки вы хотите создать, а затем на основании этой информации решите, какие проекты вам нужны. Это поможет вам распределить код по проектам.
• Начните с простейшего варианта - одиночного решения. Усложняйте структуру, только если это действительно необходимо.
• Проектируя структуру с несколькими решениями, сделайте следующее:
  • Учитывайте зависимости проектов. Старайтесь объединить в одном решении проекты, имеющие зависимости друг от друга. Это позволит использовать ссылки проекта в рамках решения. Использование ссылок проекта вместо файловых ссылок позволяет синхронизировать параметры конфигураций (Debug/Release) Visual Studio, а также отслеживать версии для определения момента очередной сборки проекта. Попытайтесь сократить количество ссылок проекта, указывающих в другие решения.
  • Продумайте общее использование ресурсов. Размещайте в одном решении проекты с общим кодом.
  • Учитывайте структуру групп. Компонуйте решения так, чтобы облегчить работу группам, занятым разработкой связанных проектов.
• Сохраняйте "плоскую" структуру проектов, чтобы удобнее было объединять их в решения, не меняя структуру файлов или папок системы управления исходным кодом.

Одиночное решение

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

Рис. 3.1. Метод одиночного решения

Вот основные доводы к использованию этой структуры:

• Сценарии сборки просты.
• Легко составить карту зависимостей между проектами в пределах решения. Такую структуру следует использовать, если все разработчики пользуются одним решением и имеют один и тот же набор проектов. Это не всегда возможно при разработке больших систем, где требуется упорядочивать проекты по подсистеме или функции.

Решение с разделами

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

Примечание В отличие от предыдущих версий, система Visual Studio 2005 основана на MSBuild. Это позволяет создавать структуры решений, не включая в них все проекты, на которые имеются ссылки и тем не менее производить сборку без ошибок. При условии, что сначала выполняется сборка основного решения, при которой происходит генерация двоичных файлов для каждого проекта, система MSBuild способна отследить ссылки проекта, выходящие за рамки решения, и успешно выполнить сборку. Это сработает только в том случае, если вы используете ссылки на проекты, а не на файлы. Созданные таким образом решения можно успешно собирать из командной строки сборки Visual Studio или из интегрированной среды разработки, но по умолчанию не в Team Build. Чтобы провести успешную сборку в Team Build, используйте основное решение, включающее в себя все проекты и зависимости.

При работе с несколькими решениями используйте плоскую файловую структуру во всех ваших проектах. Типичный пример - приложение, в котором имеется проект Microsoft Windows Forms, проект ASP.NET, служба Windows и набор проектов для библиотек классов, которые используются некоторыми или всеми вышеперечисленными проектами.

Вы можете воспользоваться следующей плоской структурой применительно ко всем проектам:

• /Source
• /WinFormsProject
• /WebProject
• /WindowsServiceProject
• /ClassLibrary1
• /ClassLibrary2
• /ClassLibrary3
• Web.sln
• Service.sln
• All.sln

Рис. 3.2. Метод решения с разделами

На рис.3.2 проиллюстрирован метод решения с разделами

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

Причины, по которым следует использовать эту структуру, таковы:

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

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

Несколько решений

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

Вместо этого следует использовать сценарий, в котором указан порядок сборки решений. Одна из центральных задач обслуживания нескольких взаимосвязанных решений состоит в контроле за тем, чтобы разработчики случайно не создали циклические ссылки между решениями. Эта структура требует сложных сценариев сборки и явного отображения отношений зависимости. В Visual Studio полностью собрать подобное приложение уже невозможно. Придется воспользоваться непосредственно TFS Team Build или MSBuild.

Структура с несколькими решениями показана на рис.3.3.

Рис. 3.3. Структура с несколькими решениями

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

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

Особенности крупных проектов

Большие группы разработчиков, как правило, отличаются следующими особенностями:

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

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

Резюме

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

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

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

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

Дополнительные ресурсы

• Лекция 4 В ней приведены важные соображения, которые следует учитывать при организации управления исходным кодом в TFS.
• Лекция 6 Структура проекта определяет доступные стратегии управления зависимостями в проектах и решениях. Управление зависимостями подробно описано в лекции 6.
• Перечисленные ниже разделы из части "Практикум" В них подробно описаны процедуры, обсуждаемые в этой лекции.
  • "Как структурировать приложения ASP.NET в Visual Studio Team Foundation Server ".
  • "Как структурировать приложения Windows в Visual Studio Team Foundation Server ".
  • "Как структурировать папки управления исходным кодом в Visual Studio Team Foundation Server ".
• Дополнительную информацию о структуре проекта и решения (не имеющую прямого отношения к Team Foundation Server) вы найдете в статье "Team Development with Visual Studio .NET and Visual SourceSafe" по адресу http://msdn2.microsoft.com/en-us/library/ms998208.aspx.