Non-Shared ViewModels as DataContext

Mar 21, 2012 at 6:02 PM

First off Jeremy, thanks for all the work you've put into Jounce!  I'm really enjoying using it. 

Is there a good way in Jounce of navigating to a view but specifying the data context to be my non-shared View Model instance instead of the shared view model instance?  I'm navigating from a View Model using EventAggregator.Publish(ViewNames.ViewB.AsViewNavigationArgs()) and the view is routed to a region.  The view appears fine, but the data being displayed is that of the shared view model instance.

One option I tried is to pass the data model as a parameter of the ViewNavigationArgs, and then overriding ActivateView, where I populate the shared view model instance with the data.  This works ok, but when I commit the changes back to the data model, I have to notify my original non-shared view model instance so it can update its proxy member variables with the new information.

I think my problem stems from me creating the non-shared view models in advance, but I need to do this because those view models listen to events coming from the rest of the application. 

Any ideas?

Mar 22, 2012 at 12:31 AM

Collections of objects and viewmodels, and the best way to handle them, is one place where my understanding of MVVM seems to get fuzzy.

I think I'll pass the view model instance as a parameter into ViewNavigationArgs instead of passing the data model.  That way the shared view model can initialize itself with the data model of the non-shared view model, and also tell the non-shared view model to update it's member variables whenever the user commits the changes.

It's a little tightly coupled, but since it's between the same type of view model class, I can live with it.

But if anyone has a better approach, I am eager to learn!



Mar 22, 2012 at 11:16 AM

I don't think it has to be that complicated. View models typically service up a specific purpose. For example, consider a typical grid + CRUD scenario. A view model represents the list of items in the grid, exposing those as a collection. There is no need to have multiple instances of that view model because you are always dealing with the list.

Now let's assume you have an edit view. That view uses a view model scoped to a specific item. Typically I'll share the same view model here. When the user clicks to edit something, I simply pass in the key for the model (or the entire record if it exists) to the edit view model. It will load the details and display. While the same view model is always shared, it always appears to the user as a unique instance because it updates based on the context they are visiting in.

The only time I see the need for non-shared is if, for example, you allow pop-ups so there are multiple edit views. In that case you can use the new Jounce 2 markup in XAML to specify a non-shared view model for the data context.

I'll have a more comprehensive example posted soon.

Mar 22, 2012 at 2:47 PM

Thanks Jeremy.  It wouldn't be the first time I've over-complicated things :)  Looking forward to the example.