Общий способ проектирования сложных приложений Prism состоит в том, чтобы каждый модуль реализовал интерфейс IModule, чтобы Инициализировать себя для работы. В большинстве случаев эта «инициализация» в основном касается регистрации некоторых типов с контейнером IoC. Так, в нашем случае IModule обычно выглядит следующим образом:Регистрация типов в задачах IModule и инкапсуляции
public class Module : IModule {
private IUnityContainer _container;
public Module(IUnityContainer container) {
_container = container;
}
public void Initialize() {
//register public types
_container.RegisterType<IMyPublicInterface, MyImplementation>();
//register internal dependencies
_container.RegisterType<IInternalDependency1, InternalDependency1>();
_container.RegisterType<IInternalDependency2, InternalDependency2>();
//..etc.
}
}
Наших модули, как правило, имеют только один (или очень мало) общественные тип, и многие другие внутренние классы/зависимости для регистрации.
Я немного обеспокоен, если этот подход нарушает принцип инкапсуляции? Кажется, что мы регистрируем все (как внутренние, так и общедоступные) в одном глобальном контейнере, что может размыть границу модуля (регистрация общедоступных и внутренних типов полностью одинакова) и сделать возможной возможность. Восстановите наши «внутренние», классы в других местах.
Не лучше ли регистрировать внутренние зависимости в ChildContainer?
Возможно, мы делаем что-то совершенно неправильное? :)
Является ли эта практика (регистрация в детском контейнере ради инкапсуляции) хорошо известной? Я действительно не читал об этом в контексте IModules, и мне интересно, может быть, никто не использует его = его не стоит использовать? Спасибо за Ваш ответ! – Shaddix
Это практика, где в приложениях, основанных на PRISM. у вас возникнут проблемы с созданием нескольких экземпляров одних и тех же представлений, если у вас нет дочерних контейнеров.MDI не может быть выполнена без него. – anivas