EF DbContext and WPF MVVM Pages

Question

I'm using a WPF application that creates an Entity Framework code first database. I'm having issues trying to find how to organise my DbContext with page navigation. Essentially i'm after advice on how to keep my Db up to date while still having the Menu options I have below. Technically i'm trying to follow MVVM wherever time possible, but being under time pressures there's corners I've cut and I am willing to cut more as needed.

WPF MVVM Layout

MainWindow contains a stack panel with buttons for overriding page navigation. This has created a side bar essentially of navigation. The main window also contains a frame which shows pages and uses the NavigationService to control whats displayed.

Each page has its own ViewModel whos base class instantiates a new DbContext.

The Problem When the menu bar is used to navigate, it creates a new instance of a page. The previous page saves its DbContext when it unloaded, but this is happening after the menu bar has already instantiated the new page and hence DbContext. So essentially the new page gets opened with old data, then the previous page saves its dbcontext.

Ideas?

• I can't seem to find a way to ensure that the menu bar navigation forces a save on any existing DbContexts already open.
• An awful way of doing it would be to make a copy of the menu bar exist in all the pages rather than outside the pages at the frame level; but this doesn't seem right.
• Remembering that navigation to pages can happen from other pages AND the menu bar. Is there a way that each page when created has some link to the parent window buttons.
• An event subscription of some sort? So that when a button is clicked it can force a save of the currently in use DbContext.

Answer 1

Sounds like you have two problems that interact poorly.

First, if you have multiple view models pointing at the same data/models then they should know about each other and bind accordingly. This should happen at the ViewModel layer and not go through the model layer (to avoid weird side-effects). Typically, I take pains to ensure that the same ViewModel serves every instance of the related model. When the ViewModels broker the data changes, then everybody who needs to be notified of changes is notified of changes (the point of MVVM).

Second, context management/persistence/sharing is always a tricky beast and this is at least one reason why. In general, I prefer to dial to a pole on either side of the persistence axis. ie either spawn a new context for every data read and write (populating first from the database and preserving changes so it can determine update vs. insert on writes) or spawn a single context that persists from first use/need to application close. Which way you go depends a lot on application architecture and expectations. With the web, I tend to lean to the former. With WPF, I tend to favor the later.