Введение.
Добрый день.
Я думаю, что подавляющее большинство из вас сталкивались с проблемой расширяемости приложений.
Точно так же, я думаю, многим из вас приходилось копаться в Reflection, чтобы выяснить, является ли сборка плагином к вашей программе.
Многим не понравилось то, что в .
NET сборки по умолчанию загружались в тот же домен, что и приложение, и потом их нельзя было выгрузить.
Многие, конечно, создавали объекты в отдельных доменах через CreateInstanceAndUnwrap, но всё это приходилось делать вручную.
В общем, «мыши плакали и кололись…».
С появлением System.Addin у разработчиков появился инструмент для создания расширяемого приложения, свободного от этих проблем, что называется, «из коробки».
Об этой технологии я расскажу в нескольких статьях.
Прежде чем начать, давайте разберемся в терминологии: Хост, Хост-приложение - Это, по сути, расширяемое приложение, которое, как правило, ищет и активирует расширения.
Аддин, Расширение – это модуль, содержащий некоторый дополнительный функционал для хост-приложения Возможности System.Addin Что такое System.Addin? Это новое пространство имен, представленное в .
NET Framework 3.5. По своей сути System.Addin предоставляет разработчикам модель программирования для расширения функциональности приложения.
Более того, использование этой программной модели предоставляет несколько ключевых возможностей: 1. Хост-приложение и надстройка могут иметь независимые версии.
Таким образом, вы можете создать ведущее приложение, которое будет работать со сборками расширений, созданными для предыдущих версий приложения, для более поздних версий приложения или вообще для другого приложения.
2. Возможность активировать Аддин с нужным уровнем изоляции и правами безопасности.
То есть программная модель System.Addin позволяет позаботиться о безопасности приложения, даже если Addin создан сторонними разработчиками.
Теперь ни один модуль расширения с ошибками не приведет к сбою вашей программы.
3. Поддерживает несколько уровней изоляции расширения от хост-приложения и других расширений.
То есть существует несколько возможных сценариев построения изоляции на уровне домена или процесса, тем самым повышая безопасность хост-приложения.
4. Более удобное управление сроком службы расширения.
Поскольку изоляция используется на уровне домена или процесса, то по окончании работы с плагином вам достаточно будет просто выгрузить нужный домен.
ХОРОШО.
Мы рассмотрели некоторые возможности.
Вперед, продолжать.
Архитектура Вся архитектура System.Addin построена вокруг такой ключевой концепции, как Дополнительный конвейер (Я бы перевел это как «конвейер расширения»).
По сути все скрыто под этой фразой.
Давайте посмотрим на следующий рисунок, который поясняет все об архитектуре: 
Это тот Дополнительный конвейер .
За счет всех этих сегментов в конвейере достигается необходимый уровень абстракции и обеспечивается изоляция.
Давайте посмотрим поближе.
На концах конвейера мы видим приложение Host и само расширение.
Это не самое интересное, поэтому перейдем к рассмотрению того, что находится между ними: 1. Договор .
Как видно из рисунка, контракт представляет собой интерфейс, «протокол взаимодействия» хоста и расширения и является точкой контакта между ними.
2. Далее с обеих сторон договора, адаптеры (наследовать представления), которые реализуют соответствующие просмотреть классы и оберните контракт интерфейсом, который предоставляет представление.
Кроме того, если вы не объединяете представление «Дополнение» и представление «Хост» в одну сборку, вы можете объединить представление «Хост» и «Хост» в одну сборку.
В любом случае мой вам совет — используйте для каждого сегмента трубопровода отдельную сборку.
Будет легче.
3. Ну и третий пункт просмотреть классы (должны быть строго интерфейсами или унаследованными классами).
Это соответствующие представления типов и методов, которые используются при взаимодействии хоста и расширения.
На данном этапе этой информации нам достаточно.
Достаточно просто представить, как выглядит конвейер надстройки.
Более подробно роль каждого сегмента этого конвейера мы рассмотрим в одной из следующих статей.
Также стоит отметить, что архитектура накладывает некоторые ограничения, с которыми мы сталкиваемся в процессе создания: 1. Во-первых, каждый сегмент конвейера в идеале представляет собой отдельный узел.
Виды можно объединять в одну сборку, но только в том случае, если адаптеры объединены одинаково.
2. Во-вторых, надстройки, адаптеры и контракты должны быть общедоступными и отмечены специальными атрибутами.
Смотрите картинку ниже: 
Обязательные атрибуты отмечены квадратными скобками.
Как видите, вид со стороны хоста не требует специального атрибута.
3. В-третьих, требуется соблюдение жесткой структуры папок, которую необходимо строго соблюдать для нормального функционирования конвейера: 
* Надстройки не обязательно располагаются рядом с адаптерами, представлениями и контрактами.
Расширения могут быть расположены где угодно.
Вы заметите, что каждый сегмент конвейера должен располагаться в отдельной папке, а папки AddInSideAdapters, AddInViews, Contracts и HostSideAdapters не допускают вложенных каталогов.
4. В-четвертых, поскольку наиболее типичным сценарием является активация расширения в отдельном домене, при проектировании не забывайте, что объекты, пересекающие границы домена (в качестве параметров или возвращаемых значений), должны быть сериализуемыми.
Так.
Не больше, не меньше.
Архитектура и налагаемые ограничения на первый взгляд могут показаться слишком сложными, но на самом деле это не так.
Думаю, теперь многие из вас имеют представление о том, что такое System.Addin. Вот и все.
В следующей статье я покажу пример, демонстрирующий использование System.Addin. Теги: #.
NET #System.Addin #contract #adapter #view #extensibility #.
NET
-
Известный Читатель. Читалка И Словари
19 Oct, 24 -
Системный Администратор Или Аутсорсинг?
19 Oct, 24 -
Видео С Toshiba Ac100. Первая Встреча
19 Oct, 24 -
Аутентификация В Cisco Ios
19 Oct, 24
