Screen synchronization - Event Aggregator VS Caching ViewModel References...

Question

Hi, i did some homework and couldn't find any article about best practices about when to use each method..

just for clarification: When using the event aggregator pattern : each screen has it's own reference of a viewmodel, the viewmodel publish changes using the eventaggregator, which later the observers use to synchronize their state.

Caching ViewModels : every screen has the save referece of the viewmodel, the controls which are bound to the properties of the view model are synchronzied, because every screen in the app has the same reference of the viewmodel (got them from a cache), all the screens are synchronized thanks to databinding.

when to use each approach? what are the pro's con's of using each of them?

Answer 1

Well, as I see it, the event aggregator approach is more scalable and provides for a more decoupled design.

The single VM (or multiple VM caching) approach is good when scalability is not an issue, as the VM may grow to monstrous proportions as more and more views are added.

In summary, the event aggregator approach is the 'correct' approach for systems built to last, but you may use the simpler approach if you are building an internal tool for a specific limited purpose and lifetime.

Answer 2

Hi, thanks for the quick reply! what you're saying is true only if the same VM class is used for multiple screen, and satisfies the contract for each of them (in this situation the vm might contain redundant field, which aren't used in some screens that bind to it).

but this situation is easily fixed when you use composition, using a more grained approach...

btw, i agree that event aggregator is more decoupled... any other considerations?

Answer 3

hello puki,

i think that both ways r o.k, but if u wanna be a good mmi developer, u can't update stuff on screen while a user is in edit mode, so the caching may need to support some suppressing.

Answer 4

Another option which works well for common data is to bind directly to a single Observer class that exposes the necessary properties rather than having duplicated properties in multiple viewmodels that need to be synchonised.

While using an observer is more coupled than subscribing/publishing to the event aggregator, when observer interfaces are injected using an IOC container, the coupling still stays fairly loose and it is very easy to determine which viewmodels are dependent on which observers.