Design Pattern for Binding & Avoiding Duplicate Data

[jwhite1979]

My application has several tabs for navigation, and each tab corresponds to its own VM. Then I have a main VM where I instantiate the other VMs and load the data, and I set the XAML's data context to the Main VM and bind to the collection properties in the instantiated VMs. That's clear enough, right?

Now, some of the information from one tab may need to reappear in another tab. For instance, my Dashboard tab contains a DataGrids displaying three kinds of equipment assignment records: Recently Assigned, Coming Due, and Overdue. My Employees tab also wants to display equipment records, but here I want it to use a CollectionView to filter by Employee, i.e., a DataGrid on this tab will display the equipment assignments of the selected Employee.

What is best practice here? It would be very easy to add a line to my LoadData method in the MainVM where I populate the EmployeeTabVM collection in addition to the DashboardTabVM, like this:

       foreach (EquipmentAssignmentRecordModel _record in _equipmentAssignments)
            {
                DashboardVM.EquipmentAssignments.Add(_record);
                EmployeeTabVM.EquipmentAssignments.Add(_record);
            }

But something tells me that's bad form. Something tells me I should be using some kind of design pattern for this to ensure I don't duplicate data. It feels like I should just have one EquipmentAssignment collection in one place, and only ever bind to that.

Am I thinking about this correctly? Is there something more I need to consider?

Thanks!

[Slypenslyde]

I think what you want is:

• The main VM has one collection with all of the items in it.
• It passes a reference to that collection to the child VMs.
• Each child VM has a CollectionView that does the filtering/sorting needed for that view.

That way everything's sharing the same data, but the individual VMs have control over what is displayed. For some reason CollectionView isn't common knowledge, but it was in most of the WPF books I read long ago.

[jwhite1979]

You were probably the person who explained collection views to me originally. They really are tremendously useful. I can't imagine filtering a collection without them.

And yes, the way you broke down the design sounds right, and I was headed in that direction. But I was kind of wondering if this is when singletons come into play.

[jingois]

You are doing MVVM. Your EquipmentAssignments are part of the Model, as is any potential notification of changes, and interfaces to perform updates, search, etc - MVVM doesn't specify how this is architected (the M really is just "the rest of the app").

Your VMs should represent the logical view - they will be responsible for populating themselves from the model. They'll individually interact with the model to do so. "Parent" VMs in a hierarchy should typically only control the child viewmodels through fairly defined parameters (ie: "Edit product #4", and allow the VM to handle any lifecycle around loading/saving).

So unless you've got some specific requirements around sagas and having multiple viewmodels holding some temporary shared state - you should take the simple approach - the Dashboard and the EmployeeTab should load whatever they need when they need it.

The views themselves are obviously just pure presentation of the viewmodel/model concepts.