Автоматический контроль архитектуры в Visual Studio

Как вы не знаю, но я себя на этой картинке узнал. Ведь, согласитесь, когда проектируется архитектура приложения, все красиво, логично и соответствует лучшим мировым практикам. Но в процессе работы, сталкиваясь с ограничениями предъявляемыми архитектурой, мы зачастую думаем: «Вот здесь немножко нарушу, это ведь сэкономит мне час времени разработки. Ну а потом, как будет время, поправлю». Но, почему-то, это время так никогда и не наступает. На мой взгляд, единственным способом заставить себя, как программиста, следовать разработанной архитектуре, это научить среду разработки все отклонения и костыли показывать как ошибки компиляции. В этом случае, если код плох, он сразу будет исправлен, ну а если архитектура устарела, то будет исправлена она. Т.е. в хранилище кода всегда будет код соответствующей запланированной архитектуре.
Пара слов, о том, что будет подкатом:
1. Небольшая преамбула.
2. Восстановление архитектуры по имеющемуся проекту.
3. Настройка Visual Studio и TFS для автоматического контроля архитектуры.
Под катом много картинок и желание все описанное попробовать.

Итак, обещанная преамбула. Почти год назад, Дмитрий Андреев (dmandreev ^[1]) уже публиковал статью ^[2] на эту тему. Я эту статью с огромным удовольствием прочитал, и, собственно, именно она меня подвигла заняться вопросом применения Layer Diagram в процессе разработки приложений. Кстати, дочитав до этого места, вы уже сходили по приведенной ссылке и прочитали то, что написал Дмитрий? Нет, ну тогда давайте, я вас подожду, а потом пойдем дальше. Жду.
Ок, теперь когда у нас с вами есть общее понимание Layer Diagram можно заканчивать с преамбулой и переходить к практической работе.

Подготовка демонстрационного проекта

Для демонстрации работы с Layer Diagram, я возьму проект, чуть более близкий к реальности, чем рассмотрел Дмитрий. Пусть у нас будет слой доступа к данным (я буду использовать Entity Framework) и, собственно, слой клиентских приложений в котором также будет слоистая структура (MVVM). В клиентском уровне модель будет браться из первого слоя, а вот слои View и ViewModel будут размазаны по нескольким сборкам.
Вот так, эти четыре проекта выглядят после создания:

Я думаю все, изменяют Namespace по умолчанию для создаваемых сборок? Ну вот, и в этом примере, для 3-х клиентских сборок я заменю Default Namespace:

Добавляем в проект DAL базу данных и Entity Model. В клиентских проектах создаем папки View и ViewModel. Добавляем в них тестовые компоненты и классы:

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

Если разбиение на слои, идет на уровне сборок, то в связи с запретом на циклические ссылки между сборками (иначе нельзя определить порядок построения), возможна только проблема «обращения через слой» (которая как раз и рассматривается в статье Дмитрия). Если же в проекте, как в данном случае, слои размазаны по нескольким сборкам, причем в рамках одной сборки есть представители разных слоев, перетаскивание проектов/файлов из Solution Explorer-а в Layer Diagram оказывается не эффективным. И тут на помощь приходит Architecture Explorer, который вызывается из главного меню: Architecture -> Windows -> Architecture Explorer. Сразу после открытия он будет иметь вид:

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

Восстановление диаграммы слоев из артефактов решения

Раз сцена готова, выпускаем актеров. Добавляем в решение модельный проект, уже в него добавляем Layer Diagram:

Да, здесь мы можем перетяуть из Toolbox-а слои, нарисовать зависимости, потом долго и упорно в эти слои переносить классы из клиентских проектов. И все это только для того, чтобы уже на следующий день, когда разработчик добавит новый класс, про который мы не знаем, и к слоям он не привязан, а следовательно проверка перестанет работать. Чтобы этого избежать, нам и пригодится Architecture Explorer.

Обратите внимание, что все классы ViewModel оказались в одном пространстве имен (ну пусть в реальном проекте они будут в 3-5), и нам теперь можно в диаграмму слоев добавлять не классы, а целиком пространства имен. Выделяем их и, не создавая никаких слоев, перетягиваем на нашу Layer Diagram:

Кстати, можем воспользоваться и функционалом перетаскивания проектов из Solution Explorer-а. С Shift-ом выделяем в нем ClientApp1, ClientApp2 и Base.Library, хватаем левой кнопкой мыши и перетягиваем на свободное место в Layer Diagram:

Переименовываем новый слой в Presentation, выделяем два слоя (View и View Model) и перетаскиваем их в слой Presentation:

Практически все готово, не хватает только связей. Для того, чтобы их сгенерировать, достаточно вызвать контекстное меню на Layer Diagram-е и выбрать пункт Generate Dependencies:

Теперь, наша диаграмма слоев приняла законченный вид:

Если у вас возникает вопрос, по поводу стрелки от ViewModel к View, то посмотреть мнения на эту тему, а может и принять участие в обсуждении, можно на форуме MSDN ^[3].

Автоматический контроль архитектуры

Ну и последний момент, как заставить диаграмму слоев автоматически, при каждом построении проверять, что код соответствует архитектуре? На самом деле достаточно просто. Для демонстрации, я в ClientApp1, в папку View добавлю компонент, который будет напрямую обращаться к слою доступа к данным:

Запускам построение и видим: Build succeeded. Для того, чтобы билды при ошибках архитектуры падали, необходимо открыть свойства модели из Solution Explorer-а (через контестное меню или выбрать и нажать F4) и включить проверку архитектуры:

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

Двойной клик на ошибке, сразу привод к месту, в которое забит костыль.
Конечно, проверка зависимостей приводит к увеличению времени компиляции, поэтому можно собрать два решения, одно с которым работают разработчики (в него не включать Modeling Project), а второе, с тем же набором проектов и Modeling Project, для автоматических построений в Team Foundation Server. В этом случае на рабочих местах построение идет быстрее, а контроль архитектуры выполняется на сервере, причем по ошибкам построения, могут сразу генерироваться баги.
Перед тем, как перейти к выводам, небольшая ремарка. Все описанное в данной статье работает и в Visual Studio 2010 и в Visual Studio 2012. Единственно, требуется версия Ultimate или Premium. Если у вас нет лицензии на соответствующие версии Visual Studio 2010, то Release Candidate версию Visual Studio 2012 Ultimate можно скачать здесь ^[4].

Выводы

1. Layer Diagram это инструментарий, про который надо как минимум знать, и в новых проектах начинать применять
2. Автоматическая проверка архитектуры позволит снизить количество «костылей» забиваемых в спешке или по не знанию
3. Правильное именование пространств имен и применение Architecture Explorer-а позволяет существенно сократить время на восстановление архитектуры
P.s. Если в данной статье, про что-то и забыл рассказать, то прошу на меня сильно не ругаться, и читать первоисточники: Визуализация существующего кода ^[5].

Автор: Teacher