Рекомендуемый способ замены сборки репозитория приложения

Question

У меня есть приложение, которое содержит сборку репозитория. Когда приложение изначально установлено, репозиторий очень прост: локальное хранилище файлов JSON. Но я хочу дать своим конечным пользователям возможность использовать другое хранилище репозитория (SQL, Oracle и т. Д.).

Будет ли это так же просто, как замена исходной библиотеки хранилища в каталоге приложения новой библиотекой хранилища? Если это так, сможет ли пользователь просто скопировать и вставить новую DLL-репозиторий в каталог приложения, перезаписав исходную DLL-библиотеку? Есть ли лучший способ сделать это?

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

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

Answer 1

Есть несколько подходов к этому вопросу, и из вопроса я не уверен, какой из них больше подходит для ваших нужд.

1. Если вам нужно только выбрать поведение из нескольких реализаций, расположенных в DLL, которые могут быть загружены при запуске приложения, вы можете ссылаться на них статически. При запуске вы можете просмотреть AppDomain для загруженных сборок (проверьте метод AppDomain.GetAssemblies()) и классов в сборке и создать словарь доступных поведений. Этот словарь впоследствии можно будет использовать для переключения между поведениями.

2. Если вам действительно нужно, чтобы пользователь обрабатывал файлы DLL во время выполнения, проверьте методы AppDomain.Load(). Они позволяют динамически загружать новую сборку в текущем AppDomain. Классы в этих сборках могут быть приведены к соответствующим общим интерфейсам для фактического вызова. Тем не менее, обратите внимание, что загрузить сборку легко, а выгрузить сборку (если вам нужно это сделать) НЕТ.

3. Поэтому, если вам нужно динамически загружать и выгружать сборки, они должны обрабатываться в другом домене приложений (проверьте метод AppDomain.Unload()). Более того, вызовы методов между доменами приложений не могут выполняться напрямую, они требуют маршалинга, что увеличивает сложность кода.

Это краткое изложение этих решений, есть статьи, подробно описывающие каждое из них...