UOW persistance, region management, MVVM, EF, and Prism

Topics: Prism v4 - WPF 4
Jun 16, 2012 at 1:50 AM

Can anyone provide a link to a sample (or guidance) where Prism region persistance is tied to units of work? I realize this is a very general request but while my question isn't specific it should be fairly common.

If you reference the QuickStarts and look at the UICompositionQuickStart you will get an idea of where I want to go. A very basic app with a list of employee names down the left navigation and when you click on a name you get a tabbed interface with details on that selected employee.

Now what I want to add is the ability to update that information, which shouldn't be an issue. But let's say I'm using EF and after I'm done with the update I hit Save. I want to make sure that the data I just updated isn't in cache anymore. From what I read about dbContext and the EF, the best method is to dispose of the context and force the next read to come from the DB and not from cache. That's where I hit a wall.

From what I understand on the UICompositionQuickStart (and nearly all other samples out there) the data in the sample is retained for the life of the application. Reading articles like this (http://www.paulstovell.com/unit-of-work) what I'd like to do is have each edit window for an employee be a unit of work that lasts only until the user closes (or saves) the window. To do that, I can't have (or at least I don't think I can) a single data context for my left navigation of employees and the context used for my employee edit. If I did, once I disposed of my context my navigation list on the left would disappear.

Sorry for the lengthy post. I've been reading a lot on the topic and a bit confused as to how to solve what is probably an easy coding approach issue.

Jun 18, 2012 at 6:54 PM


So far, I'm not aware of a specific sample which combines Prism, MVVM, EF and the Unit of Work pattern. As far as I know, Prism does not provide specific guidance on how to implement this scenario, I believe this is mainly because Prism is agnostic of which data access and persistence strategy you decide to implement, as it allows you to use any data access layer implementation depending on your personal preferences and the requirements of your scenario.

Also, as these implementations will be tied to your Model classes and not your custom presentation logic, you should be able to use any EF and Unit of Work articles to learn about them, and should be able to implement them without major problems.

For example I believe you could find the following resources useful as a starting point, as they may give you some hints and ideas on how to achieve this kind of scenarios:

I hope you find this useful,

Agustin Adami

Jun 18, 2012 at 9:27 PM

Thanks for the reply. Now that I think about it more, you are correct in that Prism could be considered ignorant of the key points of my question. And those points are better directed to the EF, UOW, or MVVM folks. The examples you provided were informative but mainly stuff I had seen before which actually ignore the issue of persistence that I am trying to resolve.

I went back and started reading the Prism Patterns and Practices guide and focused on Chapter 8 where it discusses navigation. I'm still processing all the information in the chapter but one topic relates directly to this post:

The IRegionMemberLifetime interface defines a single read-only property, KeepAlive. If this property returns false, the view is removed from the region when it is deactivated. Because the region no longer has a reference to the view, it then becomes eligible for garbage collection (unless some other component in your application maintains a reference to it). You can implement this interface on your view or your view model classes. Although the IRegionMemberLifetime interface is primarily intended to allow you to manage the lifetime of views within regions during activation and deactivation, the KeepAlive property is also considered during navigation after the new view is activated in the target region.

If I were able to resolve my data layer persistence issues and somehow make a simple app that launched an edit view based on a list of employees, I would want the data used in that view to be disposed when finished (or when replaced). The KeepAlive implies that this could happen but I believe it is only allowing garbage collection to happen and not forcing it. I think I could put a call to the Dispose() step in my view model but that does no good if it isn't used when the presentation view is removed from the region.

If Prism just marks a replaced or removed view as available for garbage collection then it isn't enough for me to rely on it disposing of my cached data in EF. That would mean I need to come up with explicit methods of making sure the cached data was refreshed or removed from EF after certain actions were taken on the view. Without sitting down and writing the code this idea seems counter productive as it ties view model to the view.

Jun 19, 2012 at 1:27 PM


Have you considered implementing the INavigationAware interface in your view models. This way you could benefit from the OnNavigatedFrom method defined by this interface which is called before the navigation takes place, allowing the view to save its state or any changes the user has made.

You could find more information about this in the following section of the Prism documentation.

I hope you find this handy,

Agustin Adami