Refresh data in view model

Topics: Prism v4 - WPF 4
Dec 12, 2012 at 6:57 PM

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?

Developer
Dec 12, 2012 at 8:04 PM

Hi,

In my opinion, using the EventAggregator to inform your view models of changes seems to be a reasonable approach as you would be able to communicate your view models with your repository in a loosely coupled way without using strong references. Also, besides the EventAggregator, Prism provides other approaches to communicate loosely coupled components that you could find interesting:

Regarding the approach of updating only the view models of the views that are visible, I believe it could be an interesting and useful method to increase the performance of the application. However, you will need to add some custom logic to determine when a view model should update its models or not. For example, if a new unit of work is available but the view is not visible, this means the view model will not be updated and thus, it has to be updated later when the view becomes visible again.

As you mentioned, you could use the INavigationAware interface in scenarios where the views are being navigated to and from. However, I believe you could also take advantage of the IActiveAware interface in order to know when a view / view model is active or not. Usually, a view is active when it's visible and inactive when it's not being shown. Hence, this interface could be handy to know when a view is visible or not.

Finally, about destroying the views when they are hidden, this is also a plausible approach. Although this approach is more resource demanding (as you mentioned) how much expensive it's will depend mostly of your application. If in your application the user will switch through a lot of views (that would be destroyed and re-created each time), the cost of this approach could be even higher than simply updating all view models regardless if they are visible or not. Hence, in my opinion, the previous approach seems to be a better choice.

Regards,

Damian Cherubini
http://blogs.southworks.net/dcherubini

Dec 18, 2012 at 7:12 PM

Thanks for this Damian - IActiveAware was exactly what I was looking for.