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!
In MVVM, the business logic is built into the Model. The ViewModel is there to bridge between the View and the Model, so it's logic only pertains to driving the display and updating the model from user interactions with the View.
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With