Best way to create a ViewModel in MVVM

Assume I have a class called Customer. Now I need to render the customer on view. So I created CustomerViewModel to use in binding. I am looking for the best way to create the CustomerViewModel class. Following are my thoughts on creating it.

1 - Create all the properties in the customer again on the view model. Inject the customer instance into view model and each properties will retrun the value from this customer object. Advantage of this method is that I can create a common base class for all view models and have common functionality dumped there. Disadvantage will be the time required to create all the properties again on the view model and doing the maintenance.

2 - Derive the view model from customer. So I have all the propeties of customer in v开发者_如何学编程iew model. But this will not allow me to use a common base class and put common view model logic there.

So I am wondering what will be the best method to create a view model? Is there any alternative methods that are better than what I thought?

You should consider reading Josh Smith's article on MVVM.

He also have a framework called MVVM Foundation that has a ViewModel base class. In general I think that the way he implements ViewModel's is the best overall.

Option 1 is much better. The reason is that you want to be able to vary these two layers independently. Having a tight coupling between your domain model and your view model will introduce rigidity in your development process which you want to avoid.

The way I deal with having to write so much code is that I don't. I use T4 templates, some reasonable conventions (properties, by default, show up in the view model; the domain model classes implement INotifyPropertyChanged and these are delegated upward), and a config file to handle projection/flattening and generate the view models. I also generate them as partial classes to be able to deal with adding other code as needed to them.

If your original Customer class does not support data binding then you will be forced to create a viewmodel class and replicate the Customer class's properties.

If however your Customer class already implements support for data binding (it either has dependency properties OR implements INotifyPropertyChanged) then there's no fundamental reason why you can't bind directly against the properties of the Customer class.

You may of course have other considerations - you may want to have your viewmodel perform certain operations in response to property changes or you may not want Customer objects to be directly modified. In which case you'll still want to wrap the Customer class.

Also, you may want to support data validation via the IDataErrorInfo interface in which case if your customer class doesn't implement this interface you'll also probably have to wrap it.