Реализация архитектуры плагинов - динамическая загрузка DLL

Question

У меня есть приложение, которое в основном разработчик с предварительно загруженными элементами управления, где вы можете создавать свои страницы, используя элементы управления.

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

Сейчас я использую XML-файлы в качестве аддонов для указанияэлементы управления, его поведение, его стили и т. д. Каждый xml (аддон) представляет отдельный элемент управления.Но я считаю, что это очень сложно реализовать, так как я должен написать универсальный синтаксический анализатор для чтения всех плагинов.

Вместо этого я могу выпустить DLL для каждого дополнения, что дает мне больше возможностей для написания кодаопределить поведение / внешний вид элемента управления и динамически загрузить его через основной движок?Если да, то как я могу проверить dll и динамически загрузить его в свое приложение?

Answer 1

Возможно, вы захотите взглянуть на Managed Extensibility Framework .Это, вероятно, решит большинство ваших проблем и даже больше, но потребует изучения некоторых новых технологий ...

Вы также должны обязательно заглянуть в пространство имен System.Addin, как подсказывает Матье!

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

• интерфейс для аддонов в вашем основном приложении
• реализация этого интерфейса в dll
• loaddll во время выполнения с Assembly.Load
  • , вы можете захотеть посмотреть на загрузку сборок аддона в отдельный домен приложений

Answer 2

Вы должны взглянуть на пространство имен System.Addin, так как оно действительно соответствует вашим потребностям. После того, как надстройка разработана, вам просто нужно поместить ее в папку, и она будет доступна (во время выполнения) для вашего приложения.

• http://kentb.blogspot.com/2008/06/maf-gymnastics-skeletal-solution.html

См. Этот вопрос для сравнения: Выбор между MEF и MAF (System.AddIn)

Answer 3

Упомянутые маршруты MEF или System.Addins, вероятно, являются наиболее эффективным способом решения этой проблемы.Я только хочу сказать несколько слов об альтернативах.

Я несколько раз «свернул» это решение вручную, и я бы сказал, что если нет веской причины сделать это с нуляЛучше использовать существующую платформу надстройки.Но если вы собираетесь это сделать, я обнаружил, что контейнеры для инъекций зависимостей, такие как Castle или (вставьте предпочитаемый вами DI-контейнер здесь), помогут справиться с некоторыми механиками.

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