Структурирование проектов и решений в Microsoft Visual Studio Team System - Сегментированное решение

Written on . Posted in Разработка и тестирование

ОГЛАВЛЕНИЕ

Страница 4 из 6

Сегментированное решение

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

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


Рис. 3.2 Подход с использованием сегментированного решения
 
При работе с несколькими решениями все проекты должны иметь плоскую структуру. Типичный пример – приложение, включающее проект Microsoft Windows® Forms, проект ASP.NET, службу Windows и ряд библиотек классов, которые совместно используются некоторыми или всеми перечисленными проектами. Для всех проектов может использоваться следующая плоская структура: /Source /WinFormsProject /WebProject
/Source 
     /WinFormsProject 
     /WebProject
     /WindowsServiceProject
     /ClassLibrary1 
     /ClassLibrary2 
     /ClassLibrary3 
     Web.sln 
     Service.sln 
     All.sln

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

Основания использования этой структуры:

  1. Повышение производительности при загрузке и сборке составляющих решений.
  2. Возможность использования составляющих решений для создания представлений наборов проектов, созданных определенной подгруппой, или на основании границ совместного использования кода.
  3. Возможность использования главного решения для сборки всего приложения.
  4. Возможность без труда отображать зависимости между проектами в каждом составляющем решении.
  5. Упрощение системы в целом, если решения выделены логично. Например, если решение выделено соответственно технологическим или функциональным характеристикам, новым разработчикам намного проще понять, над каким из решений работать.

Основная причина не использовать эту структуру:

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

форум программирование