Question

I’m rewriting an app to be based on Prism. It was based on WAF, and it uses the Entity Framework to access data via the unit of work / repository pattern.

I’m intending to use the event aggregator to inform my view models when a new unit of work is available (eg, after a save). They can then replace the model objects they are presenting with the new equivalents from the new unit of work.

1.) Is this a reasonable idea? How else could I inform my view models that they are showing out of date information?

I only want to have the view models that are visible re-query the database. ViewModels that are not currently shown can delay their refresh until they are shown (I’m planning to do this using the INavigationAware interface).

2.) Again, is this a reasonable way to proceed? How can I distinguish between view models that are currently visible to the user, and those that are not?

As an alternative solution to 2.), I’m considering creating views only as needed, and destroying them immediately when they are hidden. This would solve the “which view models are visible” question, but seems very expensive.

3.) Is Prism intended to be used in this manner?

Answer 1

1.) Is this a reasonable idea? How else could I inform my view models that they are showing out of date information?

This boils down to dealing with dirty data be it needing saved or needing refreshed. One way to solve this is that the ViewModel pulls its data from a Service, which would allow the data to get refreshed on demand.

2.) Again, is this a reasonable way to proceed? How can I distinguish between view models that are currently visible to the user, and those
that are not?

If you are going to also leverage IoC and DI via CI, the ViewModel should exist as needed and get injected into the View at runtime upon construction. To manage state and persistence of data, you should leverage the a Service for that.

3.) Is Prism intended to be used in this manner?

Prism is a buffet of services; Prism is not a single offering. The EventAggregator is to be used for cross module communication. If your communication is spanning modules, yes this would serve well to use. If the communication is internal, simple eventing would suffice.

The concept of visible will depend on your application. IActiveAware is simply an interface, not the implementation. If your application was structured in a tabular manner, IActiveAware would serve well in that environment. Again, implementation details are important in how you use the interface but are driven by application structure.