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.