MVVM - Using simple model as it's own view model is a bad practice?

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 do开发者_如何学编程n'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?

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.

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.

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.

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.