Описание
Подготовка среды
Чтобы успешно реализовать повторяемую архитектуру с использованием средств архитектуры, необходима эталонная архитектура для вашей проблемной области. Можно создать собственные или использовать один из предоставляемых группой шаблонов и практик. Вы можете найти набор ссылок описания архитектуры по следующему адресу: Application Archetypes.
Основываясь на выбранной архитектуре, создается набор преобразований по умолчанию из эталонной архитектуры к набору решения Visual Studio для реализации архитектуры.
Этот сценарий будет описывать некоторые общие шаги, которые можно предпринять для создания такой повторяемой архитектуры и даст вам советы и методы для удачного старта.
Шаблоны проекта моделирования Visual Studio
Как только вы решили, какой тип архитектуры необходим для вашей системы, вы можете начать создание проекта моделирования. Чтобы позволить воспроизводить архитектуру неоднократно и последовательно, можно создать шаблон проекта моделирования с вашего первого. Позже вы можете его уточнять итеративно.
В проекте моделирования вы описываете архитектуру с точки зрения модели. Вы выполняете разные представления этой модели, с помощью диаграмм, таких как варианты использования, компонентов, активностей, последовательности и UML-схемы классов.
Создается набор артефактов в проекте моделирования, на основе архитектурного типа проекта и выбранного архитектурного стиля. Дополнительные сведения о типах архитектуры смотрите Application Archetypes.
Есть два важных момента, которые необходимо иметь в виду при создании шаблона проекта моделирования архитектуры.
- Обеспечить хорошую структуру модели UML, где элементы модели хранятся в небольших единицах в проекте моделирования и находятся под контролем версий
- Обеспечить сотрудничество между архитектором и разработчиком, разбивая решения на проекты, где разработчик и дизайнер могут добавлять артефакты. Иметь один проект моделирования, принадлежащий архитектору.
Если вы посмотрите на реальные проекты, вы заметите, что многие приложения состоят из нескольких решений Visual Studio. Рекомендуется разделить ваше приложение слоями. Классическое многофункциональное клиентское приложение имеет три четко различимых слоя, называемых пользовательский интерфейс, бизнес-логика и доступ к данным. Обычно существует также четвертый слой, который называется что-то вроде перекрестный. Основываясь на этих слоях, вы можете создать четыре решения Visual Studio, которые содержат реализацию одного слоя. Таким образом, решения являются небольшими, и это обеспечивает решение управляемым в среде Visual Studio.
Если вы создаете шаблон моделирования для точно такого же решения, вы должны создать решение, содержащее по крайней мере 5 проектов моделирования: один для архитектора и один проекта моделирования для каждого слоя (или решения кодирования).
Идея заключается в том, что архитектор теперь может работать в основном проекте моделирования, в то время как проекты моделирования для каждого слоя используются дизайнерами и разработчиками этого слоя. Каждый проект моделирования-слоя является составной частью двух решений: Общее решение моделирования и специфическое решение для слоя. На картинке ниже отображен проект моделирования для проекта с архитектурным типом приложения толстый клиент.
Проекты моделирования и ссылки решений
| НАБЛЮДЕНИЕ Один побочный эффект этого подхода – это независимые друг от друга проекты моделирования (и их основных хранилищ). Это означает, что если разработчик, работающий в уровне представления, создает схему классов в рамках соответствующего проекта, они не будут отражены в общем проекте модели архитектуры в хранилище модели архитектора. Это благословение и проклятие. Таким образом, разработчик может использовать возможности моделирования без изменения в архитектуре, но с другой стороны, модель архитектуры и модели проектирования не могут ссылаться друг на друга. Можно, однако, синхронизировать это вручную или использовать расширяемые API для написания кода, которые позволяют делать это программно. |
Помимо этой структуры решения есть вторая часть проекта моделирования, который важен для установки стандартизованной структуры. Это структура пакета, используемая для проекта моделирования с точки зрения модели UML.
Наиболее часто используется структура, так называемая представление 4+1. Подробно об этом способе структурирования архитектурной документации смотрите в Интернете: 4+1 architectural view model.
Если вы создаете архитектуру на основе Unified Modeling Process и используете представление 4 + 1 для того чтобы разделить артефакты архитектуры, следующая структура модели UML будет хорошей отправной точкой:
Проект моделирования 4+1
После того как вы определили такую структуру для проекта моделирования архитектуры, вы можете сохранить все решение для использования в будущем в качестве шаблона. Чтобы сделать это, можно использовать плагин на сайте MSDN code gallery, который позволяет экспортировать решение Visual Studio как расширение VSIX, которое позволяет создавать позже другим архитекторам в других проектах.
Плагин можно найти в следующем месте: Export Template Wizard.
| VS2012 ОПОВЕЩЕНИЕ | ПРЕДУПРЕЖДЕНИЕ Плагин может не быть доступен в бета-версии. В этом случае, вам просто нужно экспортировать шаблон как zip-файл (с использованием существующих команд VS в меню файл), а затем добавить файл zip, содержащий шаблон, в проект VSIX (Add Project | Extensibility | Empty VSIX project). |
Следующие шаги показывают процесс создания такого шаблона:
| РЕКОМЕНДАЦИИ Смотрите пошаговое руководство для этого сценария: Visual Studio Architecture Guidance – Reusable Architecture HOL |
- Создайте новый проект моделирования и создайте структуру пакета, которую вы хотите использовать в качестве шаблона для будущих проектов, такая, как структура, показанная на приложение толстого клиента.
- Теперь в меню файл является новая команда Export Template as VSIX. Нажмите эту кнопку.
Export Template as VSIX
- Выберите проекты, которые вы хотите включить в шаблон
Мастер VSIX – выбор типа шаблона
- На следующей странице мастера укажите имя и описание шаблона
Мастер VSIX – выбор опций шаблона
В указанном выходном расположении, вы сможете найти пакет VSIX, что вы можете распространять между другими членам команды, чтобы они использовали шаблон проекта, и когда они будут создавать новый проект моделирования, они найдут шаблон Rich Application как один из вариантов на стартовой форме.
Вы можете найти гораздо больше информации о создании и настройке шаблонов проектов и элементов Visual Studio в следующих местах: Create Reusable Project And Item Templates For Your Development Team
Если вы хотите в дальнейшем создавать шаблоны, можно рассмотреть Feature Builder Power Tool, который находится в галерее Visual Studio. Это позволит вам добавлять руководство и элементы пользовательского меню в шаблон.
Использование корректного UML-профиля
Профили позволяют настраивать UML для конкретных платформ или областей. В профиле вы определяете набор стереотипов UML. Стереотип является тегом, который может быть прикреплен к определенному элементу UML. Например, можно определить стереотип «VB», который пользователь может прикрепить к классу, чтобы пометить его как класс Visual Basic. Можно определить дополнительные свойства стереотипа: любой элемент, помеченный стереотипом, может иметь дополнительные свойства – например, стереотип «VB» может иметь свойство FileName.
Можно определить собственные профили, которые будут использоваться для ваших проектов моделирования. Для того чтобы сделать свой собственный профиль необходимо изменить XML-файл с расширением .profile и запаковать этот файл как VSIX-файл. Этот VSIX-файл затем может быть установлен в каждой среде Visual Studio и использовать профиль как указано.
Простой пример настраиваемого профиля будет следующий файл, содержащий пользовательский стереотип, под названием WebService.
Этот стереотип веб-службы добавляет одно свойство в UML-тип пакет с именем «implementation type» и имеет два различных значения «ASMX» и «WCF».
Определение xml для этого профиля выглядит следующим образом:
После установки этого профиля, мы можем использовать этот стереотип в наших моделях.
Для более подробной информации см.: How to: Define a Profile to Extend UML.
Можно генерировать код из модели UML. При создании кода, стереотипы предоставляют пользователю способы создания кода, например, создать веб-службу или класс Visual Basic из UML-класса. Для получения дополнительной информации см. How to Generate Files from a UML Model.
После использования профиля один раз в проекте моделирования, можно экспортировать профиль, а также настройки по умолчанию для корневого пакета, таким образом, чтобы каждый последующий проект поддерживал тот же профиль, который был создан вами. Смотрите рисунок ниже:
Свойства профиля проекта моделирования
Добавление преобразований в стереотипы
Наличие решения моделирования является первым шагом на пути работающего решения, но следующий шаг – это работа архитектора вместе с разработчиком для перевода моделей и схем в рабочее программное обеспечение. На основе типа архитектуры, вы можете иметь специфический шаблон проектирования и документированный механизм преобразования диаграммы в код.
Это преобразование это то, что вы можете просто задокументировать в руководящем документе архитектуры. Но можно также генерировать код автоматически из вашей модели: How to Generate Files from a UML Model. Дополнительная поддержка в пакете Visual Studio Feature Pack June 2010. Это сейчас есть и в Visual Studio 11.
| РЕКОМЕНДАЦИИ Концепцию генерирования кода из диаграмм и анализа кода через диаграммы будет отображено в будущих версиях Rangers Architecture Guidance and Hands-on-Lab (HOL) |
Добавление диаграмм слоев в шаблон проекта моделирования
Проверка слоев позволяет не только определить архитектуру вашего приложения, но и помочь вам сохранить целостность архитектуры на протяжении всего его жизненного цикла.
Для этой цели используются диаграммы слоя. Они отображают зависимости между частями кода.
Диаграмма слоя как часть шаблона проекта моделирования
Разработчики могут проверить код по диаграммам слоев в рамках процесса регистрации изменений в системе версионного контроля. Если фактические зависимости в коде нарушают схему, отображенную в модели слоя, возникает ошибка во время процесса возврата изменений. Чтобы добиться этого, модель слоя для каждого решения должна быть в проекте, который является частью этого решения.
Кроме этого вы можете разместить все модели слоя в решении общей архитектуры (так, что каждая модель слоя появляется в двух решениях). Это позволяет архитектору работать со всеми диаграммами слоя вместе.
Для того чтобы иметь повторяемый шаблон архитектуры можно также сохранить диаграмму слоя для создания как шаблон. Смотрите Visual Studio Architecture Guidance – Extensibility Layer Diagrams – HOL, который показывает этот конкретный сценарий создания и сохранения диаграммы слоя как шаблон.
Существующие шаблоны слоев
Вы можете скачать набор стандартных приложений архитектуры в виде моделей слоев. Эти модели основаны на руководстве лучших практик Майкрософт Microsoft Application Architecture Guide.
Вы можете скачать их Application Architecture Guide Layer Diagrams. Текущий набор архитектур приложений:
- Веб-приложения
- Rich Client-приложение
- Rich Internet приложение
- Приложения служба
- Мобильное приложений
Как создать структуру решения, которая проста в обслуживании и имеет централизованные архитектурные артефакты
Цель заключается в том, чтобы позволить вам создать структуру Visual Studio для вашей архитектуры, которая проста в обслуживании и имеет централизованное расположение для всех артефактов, которые создаются и поддерживаются архитектором. Делая это, вы можете установить более строгие разрешения для определенных артефактов в управлении версиями, чтобы обеспечить, что артефакты архитектуры не изменяются разработчиками и поддерживаются только архитектором. Это настраиваемая модель; по умолчанию все пользователи управления версиями будут иметь права на изменение артефактов архитектуры.
| ПРИМЕЧАНИЕ Ничто не мешает вам создать нескольких решений, каждое из которых может ссылаться на те же проекты. |
Меньше значит больше
Если вы хотите иметь эффективные решения Visual Studio и предоставить разработчикам наилучшие возможности, вы должны держать количество проектов в решении как можно меньшим. Это конкретные руководства на основе обратной связи от Microsoft Most Valued Professionals (специалисты MVP) в данной области, которое предлагает общее правило избегать количества проектов более 10 в решении для поддержания производительности и простоты поддержки.
Если вы собираете систему, которая охватывает несколько отделов, также хорошая практика держать решения малыми и структурированными таким образом, чтобы отделы могли поддерживать и развиваться их конкретные части системы со временем отдельно.
| ВАЖНОЕ ЗАМЕЧАНИЕ Руководство вокруг решения размера и структуры на основе обратной связи от «Microsoft Most Valued Professionals (MVP)» обеспечивает вам возможность использовать инструменты способами, которые помогут вам делать задачи лучше и получить лучший опыт. Важно подчеркнуть, что руководство не политики, мандат или наилучшие практики, но одно из многих возможных представлений этой области. Вам нужно сверять руководящие принципы на вашей среде и ваших практиках, регулируя их в случае необходимости. |
С помощью Visual Studio 2010 и более ранних версий, загрузка файла решения с большим количеством проектов, как правило, занимает значительное время, особенно при использовании системы управления версиями, которая негативно влияет на общую производительность. Очевидно, чем более производительное оборудование сервера и рабочее место разработчика, тем меньше задержек пользователи будут испытывать при загрузке файлов решений и их проектов. Visual Studio 2012 года ввела «асинхронную загрузку решения», которая загружает проекты в фоновом режиме.
Хотя целесообразно иметь один файл решения, который содержит все проекты, которые составляют систему для общего понимания и, особенно, для задач построения, рекомендуется создать системные представления путем создания более детального решения. Как показано ниже, мы можем создать разные представления на всю систему, тем самым сужая проекты, улучшая общую производительность и, самое главное, фокусироваться на обеспечении простоты обслуживания. Команда функциональной возможности фокусируется на проекте 3 и 6 и будет лучше загружать решение X.3, чем полное решение X.
Разбиение решения на различные решения
Есть много различных других причины не раздуваться решения сотнями проектов, таких как не включать файлы, такие как конфигурации тестовых запусков, чтобы избежать непрерывных конфликтов слияния при возврате кода, т.к. инструменты, как правило, изменяют их во время работы.
Структура контроля версий
Цель состоит в том, что разработчики имеют возможность использовать архитектурные артефакты в решениях, в то время как фактический архитектор может создавать и поддерживать архитектурные артефакты из своих собственных решений. Поэтому следующая структура решения является лучшей для удовлетворения этих требований:
- -Продукт
- -xx-< слой решения 1>
- -xx-< слой решения 2>
- -xx-< слой решения 3>
- -xx-< слой решения x>
- -98 – Решение модели
- -99 – Общие
Структура решения архитектуры
Для того чтобы создать хорошее и простое в обслуживании архитектурное решение, можно использовать следующую структуру решения:
- Решение моделирования
- Проекта Моделирования Слоя слой 1
- Проекта Моделирования Слоя слой 2
- Проекта Моделирования Слоя слой x
- Главный Проект Моделирования
- UML-диаграммы
Структура организована таким образом, что каждая диаграмма слоя размещается в свой собственный проект моделирования Visual Studio. Этот проект затем включен в оба решение моделирования и в собственное решение слоя. Таким образом, есть общее решения, которое используется для разработки архитектуры приложения, но и отдельное решение для развития каждого слоя.
| ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ АКТИВОВ Вы можете решить ограничить изменения схемы слоев только архитекторам. Это может быть сделано путем размещения конкретные разрешений на проект модели слоев в системе управления версиями. |
Шаблоны структуры решений
На основе выбранной архитектуры, вы можете начать разработку вашего приложения.
Вы начинаете с создания нового решения Visual Studio для каждого из компонентов, который вы определили в архитектуре и описали с помощью схемы компонентов. Каждое решение создается из шаблона решения Visual Studio, который вы выбираете, на основе типа компонента. Как описано выше, Visual Studio имеет возможность сохранить решение как шаблон, который является чем-то, что вам нужно сделать для каждого типа компонента в вашей общей архитектуре.
Основываясь на компоненте, который вы хотите создать, эти шаблоны уже имеют ваши наилучшие практики такие, как обмен сборками, общий ключ подписи, названия шаблонов и структуру предопределенных папок для вашего решения. Вы можете увидеть ниже образец решения, которое можно использовать для создания веб-службы компонента. Этот шаблон проекта имеет чистую структуру, которую можно использовать для всех ваших сервисов.
Пример решения для создания компонента веб-сервиса
Ссылки на общие компоненты
Вам следует хранить в общей папке активы, такие как ключ подписи, файла информации сборки и файлы схемы.
Это общее расположение помещается в том же корневом месте управления версиями, где и ваше решение, и связывается элементами в решение вместо того, чтобы делать копию. Таким образом, вы держите единый источник для общих активов, и это позволяет вам обновлять файлы в одном месте. Чтобы добавить общий ресурс в проект, щелкните правой кнопкой мыши на проекте и используйте команду Add Existing Item и в диалоговом окне выберите Add as Link на кнопке открыть, как показано на следующем рисунке.
«Add as Link» в команде Add Existing Item
Ссылки на другие части системы не в текущем решении
Когда компоненты требуют ссылки друг на друга, следует сделать ссылку на них, используя общую папку.
Добавьте шаг после построения для каждого компонента решения для копирования сборки в общую папку. Сборки каждого компонента могут быть скопированы в отдельную вложенную папку. Таким образом, ссылки содержатся в чистоте и другие компоненты могут быть построены без необходимости пошагового построения всех компонентов.