Question

Guess we have simple model, e.g. let it be a Person { Name, Age }.

Now we want to display a list of persons.

Persons are read-only
We don t need to edit them
We don t need any additional stuff like presentation properties, etc.

Now question is if it is a good practice do not create PersonViewModel class that will probably be a copy of model class or will delegate all its properties? Is it a good idea to simply bind listbox to list of persons, not to their view models? It looks DRY enough, but what about idea of MVVM?

Answer 1

I have no issue with bypassing the VM and using the M directly in the View. Sometimes the models are so small and static that loading them into a wrapping VM is wasteful.

Answer 2

I ve created standalone ViewModels, but generally not standalone models. The reason for this is DataBinding -- most POCOs don t implement the INotifyPropertyChanged interface and adding them in to make them pseudo-Models seems to defeat the purpose of re-using a simple class AND respecting the MVVM pattern.

Now, if you KNOW you re never going to be editing them, it may not be a bad idea. A VM with simple property redirects seems a bit pointless to me.

Answer 3

As far as I m concerned, if you implement INotifyPropertyChanged, then it becomes a ViewModel, and you can bind to it. :) When I wrote SoapBox Core which is all MVVM, I took the approach that everything is a ViewModel. The only Model objects were classes from third party libraries that I brought in and wrapped in a ViewModel of my own.

Answer 4

I wouldn’t create a ViewModel for the Person business object when the ViewModel doesn’t introduce new required functionality.

You might be interested that there is a second approach in the MVVM community: Create a ViewModel per View and not per Business Object.

Sample applications that follow this approach can be found on the WPF Application Framework (WAF) website.

友情链接