В настоящее время я создаю приложение, используя последнюю версию Prism для Silverlight 4.
У меня есть модуль, и в этом модуле у меня есть два представления с моделями представления. Также у меня есть модульное представление с двумя регионами для каждого представления.
При инициализации модуля я регистрирую свои виды и модели моделей в контейнере Unity, а также регистрирую виды в соответствующих регионах.
Проблема состоит в том, что представления должны отображать что-то похожее на подробную информацию таблицы - первое представление показывает доступные объекты, а второе представление показывает детали выбранного объекта.
Мне нужен способ, как передать им изначально выбранную сущность. Вновь созданное первое представление не имеет выбранной сущности, а недавно созданное второе представление не отображает никаких подробностей.
В настоящее время я делаю так:
В модуле я создаю две модели представления и регистрирую их как экземпляры в контейнере Unity, а затем регистрирую представления как типы для соответствующих регионов. Каждое представление подписывается на EntitySelectedEvent из EventAggregator. Модуль инициализатора публикует это событие после инициализации, и таким образом два представления выбирают одну и ту же сущность.
Я знаю, это выглядит некрасиво - я пытался опубликовать это событие с одной из моделей представлений, но проблема в том, что EventAggregator в Prism не поддерживает постоянных подписчиков - это означает, что если вторая модель представления не подписалась на событие до Модель первого вида сработала, она не получит и событие. Я знаю, что это нормальное поведение EventAggregator, но я ищу решение, когда модели представлений могут инициировать события независимо от порядка их инициализации - то есть первая модель может инициировать событие до создания второй модели и второй модели получит это событие в очереди после подписки на него.
Существуют ли другие реализации обмена сообщениями для WPF / SL, которые поддерживают такое поведение или используют посредник (в моем примере это сам модуль), не такая уж плохая идея в конце концов? Одна большая проблема с посредником заключается в том, что модели должны быть созданы сразу при инициализации, и они не могут быть зарегистрированы как типы в контейнере, потому что это снова приводит к отсутствию подписчиков.