I would also have to implement a setter and getter for each field that the Model would want to expose in the ViewModel, which is repeating the work that is already done by the PersonModel. The one thing I would change is that I would make the setter private on the Person property. having it public opens it up to someone else changing the model outside of the ViewModel, which I think is a violation of MVVM due to the fact that a ViewModel is the sole representative of the Model that should act on the Model’s behalf..

Ask yourself, if you had a View hat had say 10 Models to deal with and each Model had roughly 5 fields that the View must present to a user – from a maintenance point of view, would you want to be the programmer that had to deal with the ViewModel that housed all the fields when they have to change?

Hi, I see that you expose a public get/set of the Model in your ViewModel. Do you think this is good practice? I would be concerned about others mishandling this and decoupling the Model from the ViewModel.

The picture is excellent, but the execution is not.

Your model implements UI logic. What I mean is the INotifyChanged. This should be implemented on the view model to achieve true separation of concerns.

Also the reference to the actual model object inside the view model should be private. Its not supposed to be access from the outside anymore.