How do I structure MVVM with Collections?

I'm having trouble understanding how to apply the MVVM pattern when Lists/Collections are involved.

Say the MainModel has a few properties and methods, as well as a list that contains other DetailModel objects. The DetailModel objects can be added, removed, or re-ordered.

The MainView will show a few controls related the the root model, and have a ListBox populated from the list. Each item will have it's own sub-view via a DetailModelView UserControl.

Finally, there is a MainViewModel. This has properties backed by the MainModel's properties and methods, bound to the Main View, with change notification keeping everything in sync. (Up to this point, I am comfortable with the pattern - more stating this in case there is something fundamental I am missing...)

When it comes to handling the list, I get confused. I have come across several examples where the MainViewModel simply exposes the list of DetailModels to the view, and the DetailModelViews are bound directly to the models. This functions, but is problematic. It does not consistently following the pattern (no DetailViewModel exists), and it drives me to include some UI-related code in my detail models. It seems clear to me that the MainViewModel should expose a list of DetailViewModels for the UI to bind, but I am stuck on how to implement such a thing!

How should manage the two lists (DetailModels and DetailViewModels)? I am really confused as where I initially populate the开发者_开发知识库 DetailViewModel list, and how I should handle adding, removing, or changing the order of the items to keep them synchronized!

Usually Models are nothing more than data objects. They shouldn't contain any code to do things like add/remove items from a list. This is the ViewModel's job.

In your case, I would create a MainViewModel that has the following properties:

• ObservableCollection<DetailViewModel> Details
• ICommand AddDetailCommand
• ICommand RemoveDetailCommand

If your MainModel class is a data object, you can either expose it, or it's properties from the MainViewModel as well. Exposing it's Properties is the "MVVM purist" approach, while exposing the entire Model is sometimes more practical.

Your MainViewModel is in charge of creating the initial list of DetailViewModels, and it is in charge of Adding/Removing these items as well. For example, in the PropertyChanged event for the MainViewModel.MainModel property, it might rebuild the MainViewModel.Details collection, and the CollectionChanged event for the MainViewModel.Details property would update MainViewModel.MainModel.Details

You are right to have a separate DetailModels list and DetailViewModels list. The DetailViewModels list should be a property of type ObservableCollection<DetailViewModel>. You can populate the observable list when you set the Model (or at construction time, if you pass the model into the constructor of your ViewModel.)

private ObservableCollection<DetailViewModel> m_details;
public IEnumerable<DetailViewModel> Details
{
   get { return m_details; }
}

You can the subscribe to m_details.CollectionChanged. This is where you can handle re-ordering the contents of the list in the Model.

I hope this helps.

In my experience, the only time you get away with exposing model objects to the view is if you're doing simple read-only presentation, e.g. displaying a string property in a ComboBox. If there's any kind of actual UI involving the object (especially one involving two-way data binding), a view model is needed.

Typically, a master VM's constructor will look like this:

public MasterViewModel(MasterModel m)
{
   _Model = m;
   _Detail = new ObservableCollection<DetailViewModel>(m.Detail);
}

where MasterModel.Detail is a collection of DetailModel objects, and _Detail is a backing field for a Detail property that's exposed to the view.

As far as adding, removing, and reordering items in this list is concerned, in the UI at least this will be done through commands on the MasterViewModel, which must manipulate both MasterModel.Detail and MasterViewModel.Detail. That's a bit of a pain, but unless you want to repopulate MasterViewModel.Detail after every change to MasterModel.Detail, it's really unavoidable.

On the other hand, if you've been wondering "why would I ever need to write unit tests for view models?", now you know.

Here is an answer that I think addresses this issue very nicely using an ObservableViewModelCollection<TViewModel, TModel>

It's nice and lazy. It takes an ObservableCollection and a ViewModelFactory in the ctor. I like it because it keeps state at the model layer where it belongs. User operations on the GUI can invoke commands at the VM which manipulate the M via public methods on the M. Any resulting changes at the M layer will be automatically handled by the class in this link.

https://stackoverflow.com/q/2177659/456490

Note my comment regarding SL vs. WPF