SCSF Инструкция: Моделирование и построение CAB приложений

Эта инструкция покажет вам, как начать использовать Composite UI Application Block (CAB), для построения простого приложения. Инструкция включает следующие секции:

• Требования и разработка приложения
• Разработка архитектуры
• Реализация приложения

После прочтения инструкции, вы поймете, как Composite UI Application Block упрощает создание сложных приложений, которые поддерживают различные варианты использования и позволяют работать в «раздельной среде» (disconnected environment) предоставляя гибкость и командную разработку.

Требования и разработка приложения

Пример приложения, используемого в данной инструкции, реализует общие «Hello World» сценарии, которые фокусируют вас на архитектуре и разработке приложения. Задача в этом упражнении — создать Windows Form приложение, работающее как оболочка (shell) и отображать с помощью его формы представления (view form) различные модули. Это демонстрирует «особенности раздельного приложения» (disconnected nature of the application), когда разработка отдельных модулей и общей оболочки пользовательского интерфейса полностью независимы.

Каждый вариант использования является уникальной задачей, не связанной с другими задачами в приложение (собственно в данном — простом — примере только одна задача). Вариант использования данного примера показать текстовое сообщение, созданное модулем, внутри оболочки. Приложение использует форму с вкладками, которая отображается в главном окне, но форма (form) имеет незначительное либо вообще ни какого влияния на дизайн и разработку модулей.

Разработка приложения

Composite UI Application Block дает возможность использовать различные паттерны архитектуры пользовательских приложений. Два наиболее распространенных паттерна это Model-View-Controller (MVC) и Model-View-Presenter (MVP). Оба паттерна одинаково подходят для реализации пользовательских интерфейсов, но MVP проще реализовывать. MVC требуются события, которые посылются моделью для обновления представления, тогда как MVP отдает функцию обновления представления презентеру. На изображении 1 представлены оба паттерна.

Изображение 1
Сравнение паттернов MVC (слева) и MVP (справа)

В дальнейшем в примере мы будем использовать паттерн MVP, так как его архитектура проще, и лучше поддается тестированию, а так же упрощает понимание процесса разработки. Этот паттерн используется во всех примерах к данному руководству. Чтобы узнать больше об использовании паттерна MVC, посмотрите этот раздел документации: Developing with the MVC Pattern.

Разработка архитектуры

В этом упражнении вашей задачей будет реализовать такой вариант использования (use case), как вывод текстового сообщения, сгенерированного отдельным модулем. Вы можете использовать стандартный класс WorkItem из поставки CAB как ваш вариант использования, но в данном примере, вы создадите свой собственный корневой класс WorkItem (назовем его ShellWorkItem) для работы с модулем. Отдельный модуль, используемый в этом примере, тоже содержит свой класс WorkItem, который является потомком корневого класса ShellWorkItem.

Примечание: Модули не обязательно должны содержать WorkItem. Модуль может регистрировать расширения для обмена данными, в таком случае будет достаточно только одного WorkItem класса.

Представление в данном примере — это SmartPart, которое создано как стандартный юзер контрол Windows Forms. TabWorkspace поддерживает SmartPart, что дает возможность в будущем отображать больше одного сообщения как закладки, если потребуется. Так же вы можете использовать и другие варианты контролов рабочей области (workspace controls), такие как DeckWorkspace или ZoneWorkSpase, в зависимости расположения и поведения, необходимого SmartPart. WorkItem модуля может отображать больше одного SmartPart в TabWorkspace как часть одного и того же варианта использования. Визуально, форма в данном примере содержит контрол SplitContainer с TabWorkItem. SmartPart расположен в левой панели. Если вы хотите разработать второй вариант использования, например вывод подробной информации о покупателе или продукте, вы можете сделать это, создав еще один модуль с классом WorkItem и отображать представление (один или несколько SmartPart‘ов) в правой панели. Две задачи остаются раздельными и несвязанными, но, тем не менее, отображаются в пределах одного пользовательского интерфейса.

Однако, все WorkItem являются потомками RootWorkItem. Эта взаимосвязь обеспечивает правильную работу различных вариантов использования (модулей) между собой. Например, вы можете добавить меню, панель задач, или строку состояния в оболочку, которые будет взаимодействовать с WorkItem и SmartPart из любого варианта использования (модуля).

Создание физической архитектуры

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

компоненты завершённого приложения

В решении (solution) данного приложения два проекта:
1. ShellApplication. Это — оболочка приложения. Она содержит форму, которая выступает в роли контейнера для всех вариантов использования реализованных в приложении. Эта форма включает контрол контейнера, который определяет расположение SmartPart‘ов. SmartPart‘ы выполняются и отображаются различными модулями.
2. MyModule. Это модуль содержащий WorkItem который представляет вариант использования и SmartPart, который реализует представление. Модуль так же содержит презентер, который обновляет представление внутри оболочки, в которой представление отображается. В данном простом случае, модуль локально генерирует данные для отображения, он так же ведет себя как модель.

При запуске, созданная оболочка автоматически запускает процедуру инициализации CAB. Она включает в себя загрузку и запуск всех базовых сервисов и дополнительных классов требуемых CAB. Во время инициализации, загружается модуль и код приложения создает презентера.
Между тем, CAB автоматически загружает и показывает главную форму приложения (оболочку). При возникновении события Load представления, презентер может создать данные для отображения и затем обновить представление.
Реализация приложения

В следующих 4 разделах будет рассказано, как создать определенный тип приложения:

• Создание оболочки (shell) и формы, и вывод этой формы
• Создание и загрузка модуля
• Добавление на форму рабочей области с закладками и запуск модуля
• Создание и добавление пользовательского элемента управления(user control) SmartPart в модуль и отображение результатов через этот SmartPart

Вы найдете проекты по каждому пункту в примерах, поставляемых с Composite UI Application Block. Находятся они в папке QuickStart подпапка Walkthrough.

Следующая статья: «Первый этап: Создание оболочки и формы»

Скачать: скачать документацию
Перевел: Рамиль Алиякберов a.k.a. R@Me0