Архитектура плагинов/вопрос о закате зависимости

Question

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

Моя идея состояла в том, чтобы создать новую сборку («.DataCore»), которая содержит все мои интерфейсы репозитория (IFooRepository, IBarRepository) и интерфейс IDataPlugin. Затем плагины должны реализовать все эти интерфейсы.

Пользователь указывает имя нужной сборки в файле app.config. Моя программа затем вызовет функцию в сборке DataCore, которая, в свою очередь, использует Reflection для загрузки желаемой сборки. Используя отражение, я затем ищу класс, который реализует IDataPlugin и вызывает функцию Initialize(), которая содержит все привязки DI для Ninject.

Так что моя архитектура выглядит следующим образом:

MyProgram => новый DataCoreLoader (строка AssemblyName) => DesiredDataPlugin.Initialize()

я просто не уверен, что это правильный путь , и если я действительно должен реализовать это сам, используя отражение. Я предполагаю, что существуют существующие Frameworks? Я кратко посмотрел на MEF, но не знаю, поможет ли это?

Причины, по которым я хочу, чтобы мои плагины имели по крайней мере один класс обнаружения: a) Я хочу проверить номер протоколаVersion на тот, который ожидает моя программа, определить устаревшие плагины и b) My Configuration Tool должен предложить список все DataPlugins с некоторыми метаданными, такими как Author или Description.

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

Answer 1

Это разумный способ реализации плагинов.

Answer 2

Я согласен с тем, что это разумный способ внедрения плагинов, хотя его можно было бы улучшить несколькими способами. Тем не менее, я не уверен, что для этого вам нужна архитектура подключаемого модуля, потому что .NET уже есть. Взгляните на DbProviderFactory.

Answer 3

Если вы укажете желаемую сборку в app.config, почему бы не указать полное имя класса в этом файле? Таким образом, вместо

<add key="dummy" value="DummyAssembly" /> 

Вы можете написать

<add key="dummyPlugin" value="DummyNamespace.DummyClass, DummyAssembly" /> 

Тогда вы можете создать экземпляр вы плагин с помощью класса Activator (Activator.CreateInstane)

Type DummyType = Type.GetType(DummyTypeValue); 
Activator.CreateInstance(DummyType); 

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