Дополнения (add-ins) позволяют добавлять функциональность к приложению спустя некоторое время после его сборки. Вы можете создать некоторый скелет приложения, который будет со временем получать все больше и больше функциональности, написанной как вашей командой разработчиков, так и независимыми поставщиками, которые пожелают расширить функциональность вашего приложения за счет дополнений.

Сегодня дополнения используются в разных приложениях, таких как Internet Explorer и Visual Studio. Internet Explorer - это хост-приложение, которое представляет каркас для дополнений, используемый многими компаниями, поставляющими расширения для просмотра Web-страниц. Shockware Flash Object позволяет просматривать Web-страницы c Flash-содержимым. Панель инструментов Google предоставляет специфические средства Google, которые могут быть быстро доступны из Internet Explorer. Visual Studio также обладает моделью дополнений, позволяющей расширять Visual Studio на разных уровнях.

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

.NET Framework 3.5 предоставляет каркас для хостинга и создания дополнений в сборке System.Addin. Этот каркас также известен под именем MAF (Managed AddIn Framework - каркас управляемых сборок).

Дополнения также известны подразн1ми терминами - add-on или plug-in .

Темы, рассматриваемые в настоящей главе:

□ архитектура System.Addin;

□ созданием простого дополнения.

Архитектура System.Addin

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

□ сложности, связанные с дополнениями;

□ канальная архитектура;

□ исследование;

□ активизация;

□ изоляция;

□ жизненный цикл;

□ поддержка версий.

Сложности, связанные с дополнениями

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

Таблица 36.1. Сложности дополнений Сложность дополнения Описание

Исследование

Активизация

Изоляция

Жизненный цикл

Поддержка версий

Как принимающее приложение может находить дополнения? Есть несколько разных вариантов. Один из них - добавление информации о дополнении в конфигурационный файл приложения. Это имеет тот недостаток, что инсталляция нового дополнения требует внесения изменений в существующий конфигурационный файл. Другой вариант заключается в простом копировании сборки, содержащей дополнение, в предопределенный каталог с чтением информации о нем средствами рефлексии.

О рефлексии рассказывается в главе 13.

С динамическими загружаемыми сборками невозможно просто использовать операцию new для создания экземпляра. Вы можете создать такие сборки с помощью класса Activator. Также различные опции активизации могут применяться, если дополнение загружено внутри другого домена приложений или нового процесса. Сборки и домены приложений описаны в главе 17.

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

Очистка объектов - работа для сборщика мусора. Однако сборщик мусора здесь не поможет, поскольку дополнения могут быть активизированы в другом домене приложений или в другом процессе. Другой способ удержания объекта в памяти - счетчик ссылок или механизм аренды и спонсирования.

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

Теперь давайте рассмотрим архитектуру MAF, и то, как каркас решает перечисленные проблемы. Дизайн MAF определен следующими целями:

□ дополнения должны легко разрабатываться;

□ нахождение дополнений во время исполнения должно быть производительным;

□ разработка принимающих приложений должна быть также простой, но не

□

столь простой, как разработка дополнений; дополнение и принимающее приложение должны развиваться независимо.

Канальная архитектура

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

На рис. 36.1 показан канал, лежащий в основе архитектуры MAF. В центре находится сборка контракта. Эта сборка содержит интерфейс контракта, перечисляющий методы и свойства, которые должны быть реализованы дополнением, и могут быть вызваны хостом. Левая часть контракта - это сторона хоста, а правая - сторона дополнения. На рисунке вы можете видеть зависимости между сборками. Сборка хоста, показанная слева, не имеет реальной зависимости от сборки контракта; то же касается и сборки дополнения. Ни та, ни другая в действительности не реализует интерфейса, определенного контрактом. Вместо этого они просто имеют ссылку на сборку-представление (view). Хост-приложение ссылается на представление хоста; дополнение ссылается на представления дополнения. Сами представления содержат абстрактные классы представлений, которые определяют методы и свойства, как они определены контрактом.

Рис. 36.1. Канальная архитектура MAF

На рис. 36.2 представлены отношения между классами канала. Класс хоста имеет ассоциацию с абстрактным представлением хоста и вызывает его методы. Абстрактный класс представления реализован адаптером хоста. Адаптеры выполняют соединение между представлением и контрактом. Адаптер дополнения реализует методы и свойства контракта. Этот адаптер содержит ссылку на представление дополнения и переадресует вызовы со стороны хоста к представлению дополнения. Класс адаптера хоста определяет конкретный класс, наследуемый от абстрактного базового класса представления хоста, реализуя его методы и свойства. Этот адаптер включает ссылку на контракт для переадресации вызовов от представления к контракту.

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

Исследование

Каким образом принимающее хост-приложение может находить новые дополнения? Архитектура MAF использует предопределенную структуру каталогов для нахож-