Часть 1

Источник: http://www.microsoft.com/rus/msdn/magazine...t.mspx#Section1

Примечание: Цитаты - это мои коментарии. Medved

Часть 1
• Введение
• Словарь терминов
• Как работает CAB
• Создание простого CAB-приложения
• Создание простого смарт-клиента: пошаговое руководство
• Создание модуля и его инициализатора
  
  Часть 2
• Введение в Smart Client Software Factory
• Основные сервисы смарт-клиента
• Функциональные уровни Integrated Desktop
• Интеграция устаревших Web-приложений
• Этап 1: создание Web-страницы
• Этап 2: создание Web-модуля
• Этап 3: создание нового рабочего элемента
• Этап 4: создание нового представления View
• Этап 5: компиляция и тестирование решения
• Взгляд в будущее
• Ссылки

Введение

В последнее время огромное внимание привлечено к обеспечению сотрудников информационных отделов средствами бизнес-анализа (Business Intelligence, BI), которые помогают им принимать более обоснованные решения. Большинство корпоративных средств бизнес-анализа объединяет информацию из множества источников, используя, как правило, какую-либо разновидность интеграции данных на серверной стороне. Будь то система подготовки отчетов, суммирующая данные, средство поддержки коллективной работы вроде Microsoft SharePoint или собственное решение по интеграции корпоративных приложений (EAI), обеспечивающее управление бизнес-процессами, во главу угла всегда ставится своевременная доставка этой информации. А на ее использование обращают мало внимания.



В большинстве случаев для принятия решений сотрудник информационного отдела использует несколько приложений: Web-браузер для просмотра портала, приложение для доступа к EAI-решению и средство просмотра отчетов для чтения итоговых данных. Со временем этот сотрудник приобретает необходимые навыки, научившись вручную собирать и систематизировать данные от разных приложений. Обычно это делается запуском Microsoft Outlook, Word, Excel, Internet Explorer и множества внутренних нестандартных приложений, предоставляемых компанией. Данный способ интеграции, вынуждающий пользователя крутиться волчком на своем рабочем месте, имеет чудовищные недостатки: высокие затраты на обучение новых пользователей, неспособность системы предоставить нужную информацию нужным лицам в должном формате, появление ошибок в данных и т. д. Разве не эффективнее было бы реализовать надежную инфраструктуру интеграции и хостинга с моделью развертывания, которая упростила бы данный вид интеграции приложений?

Большинство разработчиков рассматривает архитектуры, ориентированные на сервисы (service-oriented architecture, SOA), как средство доставки информации, а не ее использования. Но как управлять всеми этими островками автоматизации? Вот здесь-то и возникает идея об интеграции настольной среды.

Как архитекторы информационных решений, мы стремимся сократить необъятный простор бизнес-приложений и улучшить рабочую среду пользователя. Но здесь одной из труднейших задач является создание такого решения, которое бесшовно интегрировало бы множество приложений, запущенных на настольном компьютере. Такие технологии, как DDE, OLE, COM, почтовые ящики (mailslots) и им подобные, предназначены для интеграции локальных приложений. В результате их применения получаются жестко сопряженные, ненадежные настольные приложения, которые обычно требуют больших расходов на внедрение и сопровождение.

Integrated Desktop — новейшая реализация архитектуры подключенных систем (connected systems architecture), предназначенной для настольных приложений. Integrated Desktop — это архитектура хостинга со слабым сопряжением и составной UI, запускаемый на настольном компьютере и поддерживаемый серверной стороной на основе архитектуры со слабым сопряжением. При этом сокращается количество приложений, с которыми пользователь должен иметь дело, и все помещается в один «флакон». Все технологии, необходимые для создания приложений Integrated Desktop, уже содержатся в .NET Framework. Однако до сих пор их интеграция представляла собой нелегкую задачу.

В основе стратегии Integrated Desktop лежит поддержка сервисов. В то время как архитектура сама по себе абсолютно не требует инфраструктуры сервисов, стратегия построения составных корпоративных настольных приложений — требует. Характер приложений Integrated Desktop, слабо зависимых друг от друга, естественен для SOA-систем. Сохранение качеств архитектуры со слабым сопряжением (мало зависимых друг от друга) помогает развертыванию там, где эти разновидности архитектур часто натыкаются на препятствия.

Базовыми уровнями для Microsoft-реализации Integrated Desktop служат новые Composite UI Application Block (CAB) и Smart Client Software Factory. В связке друг с другом они становятся мощным инструментом для архитекторов решений, создающих собственную инфраструктуру клиентских приложений.


Словарь терминов

Прежде чем углубляться в технологию Integrated Desktop, разберемся в базовой терминологии.

CAB — Инфраструктура и документация, помогающие создавать сложные, слабо сопряженные смарт-клиенты, поддерживающие компоновку (composability) в период выполнения.


Context (контекст) — Относится к общим данным, совместно используемым множеством приложений. Данные контекста нужны для согласования информации между элементами, даже когда эти элементы содержатся в размещенных на хосте подприложениях внутри составного UI.


Dependency Injection — Проектировочный шаблон, реализованный в расчете на Object Builder для динамического включения объектов в составной UI в период выполнения. Это реализация проектировочного шаблона Мартина Фаулера (Martin Fowler), иногда называемая Inversion of Control.


Event Broker — Механизм взаимодействия между компонентами внутри смарт-клиента, который использует модель «издатель-подписчик», позволяющую любому элементу CAB взаимодействовать с другими элементами составного (композитного) UI.


Module (модуль) — Обозначает единицу развертывания (deployment unit) CAB-приложений. Модули содержатся в файлах сборок (DLL) и могут включать одно или несколько подприложений, которые будут задействованы в составном UI. Последний может загружать любое количество модулей.


Smart Client Software Factory — Интегрированный набор документации (демореализации, шаблоны, документы «how-to», пакеты Guidance Automation Toolkit, документация по архитектуре и примеры кода), которая вкупе с CAB и Enterprise Library делает возможной разработку сложных смарт-клиентов.


Smart Client Service — Сервис, выполняемый на клиентской стороне и предоставляющий базовую инфраструктуру для работы таких элементов смарт-клиента, как система защиты, средства развертывания, темы и т. д.


Smart Part (View) — Повторно используемый составной интерфейс, который отвечает за компонент представления в используемом CAB и Smart Client Software Factory шаблоне «модель-представление-контроллер» или «модель-представление-презентатор». (Smart Part просто поддерживает работу с Visual Studio. В большинстве случаев применимы пользовательские элементы управления.)


Theme (тема) — Отвечает за внешний вид GUI-элементов и настольного приложения в целом. Аналогична темам ASP.NET, но с учетом специфики смарт-клиентов. Для управления темами в Smart Client Software Factory используются рабочие пространства CAB или диспетчеры разметки (layout managers).


UI Elements (UI-элементы) — Интерфейсные элементы управления общего применения, используемые навигационными элементами в оболочке. В качестве примера можно привести элементы меню, панелей инструментов и пользовательские компоненты для поддержки навигации. UI-элементы можно связывать с командами и динамически контролировать из любого подприложения в период выполнения.


Work Item (рабочий элемент) — Контейнер CAB для хранения ссылок на CAB-компоненты, такие как элементы Smart Part, события, сервисы, общие данные, рабочие пространства, команды и другие рабочие элементы. Каждый рабочий элемент обычно поддерживает определенный набор свойств или же рассчитан на конкретный «случай применения» («use case») для какого-либо подприложения.



Как работает сам CAB

CAB представляет собой реализацию шаблонов и концепций, используемых при создании сложных клиентских смарт-приложений (смарт-клиентов). Проще говоря, это надстройка Windows Forms, помогающая в создании корпоративных настольных приложений.

Мы могли бы посвятить всю статью обсуждению CAB, а описание некоторых компонентов вообще в нее не поместилось. Поэтому мы сосредоточимся на основных компонентах CAB, но рекомендуем вам скачать прилагаемые к статье материалы и самостоятельно изучить их. Для начала посетите сайт сообщества CAB (EN).

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

CAB позволяет распределять задачи разработки интерфейса смарт-клиента, четко разделяя этот интерфейс на части. В итоге CAB способствует повторному использованию кода и дает возможность легко реализовать такие концепции, как рабочий процесс внутри приложения (intra-application workflow). Чтобы обеспечить возможность повторного использования, составной UI, построенный на основе инфраструктуры CAB, разбивается на несколько работающих частей. Оболочка приложения выступает в роли хоста и загрузчика ваших элементов составного UI. Загруженные и выведенные на экран с помощью оболочки, UI-элементы предоставляют пользователю точки взаимодействия вроде меню и других навигационных компонентов. Сами по себе оболочки слабо связаны с составными частями приложения, что обеспечивает гибкость при проектировании UI. Оболочка и сервисы CAB «управляют автомобилем», но вам придется позаботиться о движке приложения или приложений, для которых оболочка будет служить хостом.

CAB не только предоставляет инфраструктуру для хостинга повторно используемых элементов, но и предлагает базовый набор сервисов смарт-клиента для таких задач, как загрузка модулей, обмен сообщениями, сохранение состояния и т. д. Все это можно реализовать в коде или через файл .config вашего приложения. К базовым сервисам относятся следующие.

Загрузчик модулей и сервисы перечисления модулей
Сервисы на основе провайдеров; управляют перечислением и загрузкой модулей в настраиваемом каталоге.

Сервис Event Broker
Передает сообщения между частями приложения и между подприложениями, размещаемыми в составном UI.

Сервис аутентификации
Сервис на основе провайдеров; отвечает за проверку пользовательских учетных данных, доступ к сертификатам и взаимодействие с серверными провайдерами данных.

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

Чтобы реализовать движок CAB-приложения, обычно начинают с создания CAB-модуля. Модули предоставляют точку входа для вашего индивидуального набора средств, который иногда называют размещенным приложением (hosted application). Модули содержатся внутри собственных DLL-файлов и загружаются из оболочки в период выполнения. Доступность модулей и их загрузка полностью настраиваются и поддерживаются расширяемым каталогом программ. Если у вас есть опыт работы с Microsoft Enterprise Library, вы обнаружите, что в CAB применяется та же модель провайдеров. Модули не требуют прямых ссылок на них из проекта оболочки в Visual Studio и непосредственной привязки к исполняемому файлу. Они загружаются в период выполнения загрузчиком модулей.

Внутрь сборки модуля вы включаете рабочие элементы, представления, контроллеры и данные, которые необходимы, чтобы управлять набором средств с помощью CAB и типов Smart Client Software Factory, таких как Presenter, SmartPart и State. Эти три элемента, в частности, образуют шаблон MVP/MVC (Model-View-Presenter/Model-View-Controller), на котором базируются CAB-приложения. Сервисы подключаются по мере необходимости в соответствии с логикой приложения. Это позволяет разработчику динамически создавать новые экземпляры объектов или возвращать объекты, уже созданные внутри контейнера. Для CAB этот контейнер является рабочим элементом и одним из первых создается разработчиком модуля. Компоненты CAB, например клиентские сервисы и рабочие пространства, можно добавлять в контейнер явно с помощью AddNew:


То же самое можно сделать через конфигурационный файл или декларативно:


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


Ключевой компонент CAB — Object Builder (также используемый новой версией Enterprise Library). С помощью Object Builder (благодаря поддержке концепции Dependency Injection) теперь можно создавать новые объекты какого-либо класса или возвращать существующие, если они подходят; выбирать определенный конструктор, если в классе их несколько; сопоставлять свойства и методы с атрибутами, которые будут влиять на создание и именование нового объекта; удобно удалять параметры из существующих объектов, двигаясь обратно по цепочке операций.

Object Builder представляет собой низкоуровневую утилиту, с которой вы вряд ли будете работать напрямую. Но знание концепции Dependency Injection является ключевым для понимания того, как сервисы включаются в ваш модуль. Это знание также окажет вам неоценимую помощь при отладке. Подробнее о Dependency Injection и прочих шаблонах, используемых в CAB, см. в документации по CAB.

При желании модуль можно разбить на части произвольным образом. В каждом модуле должен содержаться минимум один рабочий элемент, служащий драйвером этого модуля. Рабочие элементы, подобно любому приложению или подприложению, могут быть как очень простыми, так и очень сложными. Для CAB-приложения характерен следующий порядок работы.

1. Пользователь дважды щелкает EXE-файл, отображающий оболочку.
2. Оболочка появляется на рабочем столе, загружает заданные CAB-сервисы, отображает UI-элементы и загружает все сконфигурированные модули.
3. По окончании загрузки каждый модуль добавляет по рабочему элементу в свой родительский элемент, чтобы управлять подприложением и выдавать запросы к рабочему элементу на показ его содержимого в поддерживаемом рабочем пространстве.
4. Когда пользователь выбирает какой-либо элемент меню, срабатывает соответствующая команда.
5. Обработчик команд реагирует на эту команду созданием дочернего рабочего элемента, который управляет другим подприложением и отображает его представления.
6. Рабочий элемент отображает свое представление с помощью Smart Part.
7. Пользователь взаимодействует с этим интерфейсом, который в свою очередь обращается к контроллеру (или его презентатору).
8. Контроллер изменяет общие данные (состояние) и связывается с хостом, используя Event Broker.
9. Event Broker отправляет актуальную информацию (контекст) другим модулям или компонентам.

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



Создание простого CAB-приложения

Теперь создадим одномодульное приложение. Сначала я объясню в общих чертах, как создается простой смарт-клиент. (Позже в этой статье я рассмотрю более сложное интегрированное настольное приложение.)

У большинства интегрированных настольных приложений есть видимая, загружаемая при старте форма. Поэтому вы начинаете с оболочки Windows Forms, наследуете свой класс от FormShellApplication, создаете его экземпляр и вызываете его метод Run из метода Main своего приложения. Это приводит к запуску CAB-приложения и загрузке всех сконфигурированных сервисов, которые мы обсуждали ранее. Следующий шаг заключается в перегрузке методов из состава FormShellApplication, таких как AfterShellCreated, с целью заполнить меню и показать все видимые представления. (Можно также задействовать элементы Smart Part, которые попросту являются пользовательскими элементами управления, дополненными SmartPartAttribute.)

Чтобы при реализации AfterShellCreated инициализировать UI, вы регистрируете так называемый узел расширения (extension site), к которому будет обращаться CAB. Тем самым вы задаете диспетчер UI-элементов, и любой модуль сможет впоследствии добавлять дочерние UI-элементы (например, меню или панели инструментов) в любую точку любого модуля. Наконец, вы выводите на экран свои представления либо при загрузке оболочки, либо в ответ на команды UI-элементов, добавляемые при инициализации. Этими командами запускаются обработчики, благодаря которым ваш код может отвечать на любые команды, инициируемые любым традиционным UI-элементом в период выполнения. Это аналогично добавлению обычных обработчиков событий, но в более абстрактной форме.

Представления можно отображать через классы SmartPartPlaceHolder или в зависимости от того, какой CAB вызывает рабочее пространство. Этим попросту задаются контейнеры разметки, используемые для вывода ваших представлений в заданном порядке. Если вы когда-нибудь работали в Java со средствами абстрактных окон (abstract windows toolkit, AWT), эта концепция покажется вам знакомой.

Наконец, чтобы создать оболочку, зарегистрируйте интерфейс и отобразите Smart Part. Чтобы задействовать реальную мощь CAB, вы используете модули для инкапсуляции частей приложения в отдельные сборки. Это дает вам абстракции на этапе разработки, подобные COM-абстракциям периода выполнения, но без лишней сложности.

С помощью модулей вы можете включать в приложения независимые наборы средств, которые распространяются в собственных сборках. То есть компания может создавать новые версии модулей и распространять их, не мешая работе приложения Integrated Desktop. Файлы сборок с модулями, на которые нет прямых ссылок в EXE-файле, загружаются в период выполнения с помощью загрузчика модулей и сервисов перечисления. Каталог профиля CAB и конфигурационный файл приложения позволяют указывать, какие модули следует загружать, развертывать и запускать в оболочке.

Поставляемый вместе с CAB пример «Bank Teller» из раздела Quick Start является готовым одномодульным CAB-приложением. Он дает представление обо всех ключевых компонентах, о которых я здесь упоминал.

Конечно, создание реального корпоративного приложения Integrated Desktop требует гораздо больше простого UI с набором элементов управления. Вам придется решить массу проблем, в частности, как согласовывать доступ модулей к совместно используемой информации, как интегрировать в приложение Integrated Desktop программы, не относящиеся к CAB, и как управлять расположением элементов интерфейса.

Создание простого смарт-клиента: пошаговое руководство

1. Создайте новое приложение Windows Forms.

2. Добавьте в проект следующие ссылки на сборки:


3. Создайте класс приложения, в котором определялось бы использование WorkItem (по умолчанию RootWorkItem) и вывод на экран формы Windows Forms. Чтобы создать класс MyWorkItem, сделайте его производным от CAB-класса WorkItem:


4. Реализуйте метод Main своего приложения, создайте экземпляр приложения и вызовите Run:


5. Перегрузите AfterShellCreated, вызовите его базовую реализацию и инициализируйте интерфейс:


6. Создайте Smart Part. Для этого введите в проект пользовательский элемент управления и добавьте ссылку на пространство имен Microsoft.Practices.CompositeUI.SmartParts. Затем добавьте в свой класс атрибут SmartPart:


7. Добавьте обработчик команд и отобразите Smart Part с помощью DeckWorkspace:


В окно инструментария (toolbox) можно добавить любое рабочее пространство CAB и перенести его на проектируемую форму подобно обычному элементу управления.

Создание модуля и его инициализатора

1. Создайте библиотеку классов или библиотеку элементов управления.

2. Добавьте ссылки:


3. Добавьте в проект ModuleAttribute, чтобы другие модули могли идентифицировать этот модуль в коде.

4. Добавьте в свой файл AssemblyInfo.cs:


5. Создайте в проекте новый открытый класс и унаследуйте его от Microsoft.Practices.CompositeUI.ModuleInit. Перегрузите AddServices, чтобы добавлять CAB-сервисы в период выполнения, и перегрузите Load для отображения любого UI.

6. Чтобы ваш модуль мог загружаться в период выполнения, создайте XML-файл ProfileCatalog.xml, который ссылается на ваш новый DLL-файл с модулем. Добавьте этот XML-файл в основной EXE-проект (оболочку, которую мы только что создали).

7. Типичный каталог профиля выглядит так:


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

8. Добавьте метод Load и реализуйте его в своем новом классе ModuleInit. В показанном ниже коде создается объект WorkItem вашего модуля с использованием метода AddNew в контексте RootWorkItem. Затем вызывается метод Run нового объекта WorkItem. Вы получаете рабочее пространство по имени и передаете это рабочее пространство методу Run. В данном примере целевым является пространство DeckWorkspace с именем deckWorkspace1:


9. Чтобы запустить свой код в ответ на запуск WorkItem, реализуйте метод Run своего класса MyWorkItem, как показано здесь:



Окончание Часть 2

Это сообщение отредактировал(а) Exception - 30.5.2007, 13:45