WPF/SL EventAggregator implementation with durable subscribers behavior?

Question

Hi. Currently I'm building an application using latest Prism for Silverlight 4. I've a module and in that module I've two views with view models. Also I've a module view with two regions for each view. In module initialization I'm registering my views and view models in Unity container and also register views with corresponding regions. The problem is that views should display something similar to table-detail information - first view shows available entities ans the second view shows detail of selected entity.

I need a way how to pass them initial selected entity. Newly created first view doesn't have any selected entity and newly created second view doesn't show any details.

Currently I'm doing that this way: In module I create two view models and register them as instances in Unity container and then I register views as types for corresponding regions. Each view subscribes to EntitySelectedEvent from EventAggregator. Module initializer publish this event after initialization and this way two views are selecting the same entity.

I know this looks ugly - I tried publishing this event from one of view models but the problems is that EventAggregator in Prism doesn't support durable subscribers - this means that if the second view model didn't subscribe to event before the first view model fired it, it won't receive and event. I know this is a normal behavior of EventAggregator, but I'm looking for a solution when view models can fire events without depending on initialization order of them - that is the first model can fire event before the second model was created and the second model will receive this 'queued' event after subscribing to it.

Are there any other messaging implementations for WPF/SL which do support such behavior or using a mediator (in my example it's a module itself) isn't such a bad idea after all? One big problem with mediator is that models must be created right away in initialize and they can't be registered as types in container because this leads again to missing subscribers.

Answer 1

Create a Model that will be shared by ViewModels of each of the views.

When a row gets selected in View 1 its ViewModel (via a CurrentEntity property bound to a selected row) will update the Model.

ViewModel of View 2 would subscribe to changes of Model's CurrentEntity and will properly update it's own CurrentEntity property that would cause it's View to update.