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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

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

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