#prism #modularity #discovery
Вопрос:
Предположим, что модуль WPF Prism версии 8 имеет модель представления, которая должна вызывать службу. служба реализует IService, но существует ряд реализаций этой службы. Каждая реализация представляет собой файл (библиотеку классов), возможно, в виде имодуля (см. Ниже).
Пользователь должен иметь возможность настроить, какой файл использовать, либо по конфигурации, либо по содержимому папки.
Очевидно(?) Таким образом, я думаю об обнаружении модуля, создав правильный тип ModuleCatalog, в то время как «начальная загрузка» приложения и службы, таким образом, может содержаться в этом модуле. Если вызов является недействительным вызовом («выстрели и забудь») Я думаю, я мог бы просто использовать EventAggregator (реализующий службу в качестве наблюдателя), однако вызов возвращает значение.
Каков наилучший подход к решению этой проблемы? (Я хотел бы избежать написания моей собственной сборки «обнаружение/загрузка» какого-либо DLL-файла реализации службы с возможностью замены)
Ответ №1:
Если вы можете сделать инъекцию IEventAggregator , вы можете сделать инъекцию IService , не так ли?
Если ни один модуль не зарегистрировал реализацию, вы получите исключение. Если это сделали несколько модулей, выигрывает последний (по крайней мере, с unity в качестве контейнера).
Комментарии:
1. Комментарий SO ограничивает количество символов, пожалуйста, смотрите последовательные комментарии: Спасибо за ваш простой ответ, который намекает мне на возможность. Оставшаяся проблема заключалась в следующем: «хорошо известный» модуль (тот, у которого есть модель представления, отныне называемый «зависимым модулем», зависит от служебного модуля. Сначала я попытался сделать оба модуля «хорошо известными» (добавив ссылку на проект из приложения к обоим модулям). Все работало нормально до тех пор, пока сервисный модуль был настроен до «зависимого модуля» в каталоге ConfigureModuleCatalog (в противном случае запуск службы в ViewModel).
2. Затем я удалил служебный модуль из ссылок на проект приложения и больше не добавлял модуль в каталог ConfigureModuleCatalog (сохранил модуль AddModule для «зависимого модуля»). Наконец, отменил CreateModuleCatalog и создал каталог DirectoryModuleCatalog для каталога с сервисным модулем в нем, затем я сразу же инициализировал этот каталог модулей, который инициализирует сервисный модуль перед «зависимым модулем», и все работает нормально.
3. Таким образом, моя проблема заключалась в том, что сервисный модуль был инициализирован слишком поздно. Хотел бы я более подробно понять, как управлять порядком, если, например, оба модуля должны быть обнаружены DirectoryModuleCatalog. А как насчет нескольких каталогов (будет ли несколько каталогов IModuleCatalog. Инициализировать() может быть полезно при условии, что свойство Path изменяется перед каждым вызовом? В любом случае, спасибо, что подсказали мне правильный подход.
4. @EuroEager вы не хотите начинать
Resolveдо того, как все будетRegisterготово. Вы должны выполнить начальную навигацию (за исключением, возможно , экрана загрузки)OnInitialized, т. е. Когда все загружено.5. Еще раз спасибо, я выполняю начальную навигацию с OnInitialized, и она отлично работает. Если сложность приложения возрастет (зависимости между модулями между обнаруженными модулями и т.д.) И произойдет что-то подобное, я спрошу еще раз