views:

71

answers:

3

Hello,

everyone speaks about wrapping a model by a viewmodel. fine so far.

But when I want persist my Model, how do I convert a ViewModel into a Model ?

Reading all properties from the ViewModel into a new Model object seems very cumbersome.

Any better method?

A: 

I'm currently converting an old winforms app into a wpf mvvm application, and I'm just providing a property on my viewmodel that points to the actual instance of the model.

From my point of view, it doesn't make sense to create a replica of the model in the viewmodel, and I don't think that the MVVM community is saying that anyway.

It particularly won't make sense when you start using entity framework or some other database orm, because entity framework has properties that support databinding out of the box. Plus, when you start making changes to the database, you have to update the model, and the viewmodel.

Edit: You're right in that ef doesn't support INotifyCollectionChanged, but as far as I know, it does support INotifyPropertyChanged, and from the looks of it, Microsoft is thinking of implementing INotifyCollectionChanged in a future release.

I don't think that there is a right or wrong way for MVVM - I think that every different 'authority' on the web has their own interpretation of how it should work.

Dave Arkell
Answer one is very vague...Replica...: Sacha Barber (wpf disciple) is replicating his CustomerModel with the Domain Customer, just check his Chinch framework sample app- I have not mentioned EF, but if you mention it, EF entities does not support INotifyCollectionChanged.
msfanboy
"...making changes to the database, you have to update the model, and the viewmodel...."not true, because the model is delegated to the viewmodel.sample CustomerViewModel.cs:public string FirstName{ set{ _customerObject.FirstName = value;}}The modelObject is injected into ViewModel Ctor ;-)but this causes problems doing aggregated Models into ViewModels... but thats another story.
msfanboy
A: 

The idea is that the ViewModel is made for the user interface. In other words, one WPF form has one ViewModel, while the ViewModel may actually use multiple models (customers, orders, etc.). If your form is only dealing with one model, then it is going to be close to a 1-to-1 mapping.

Nelson
do you have read my question?
msfanboy
A: 

Only wrap a model in a viewmodel when needed, otherwise the view will directly bind to the properties of your model. An example: Model 1: list of employees (An employee has a name and department) Model 2: list of departments. View: Show list of employees and departments. When a user selects a department, the employee list gets filtered. ViewModel: Provide a current selected department property and a filtered employee list.

View would databind the department list directly against the model 1 but the current selected department and filtered employee list against the viewmodel. Viewmodel will filter employee list depending on selected department.

Wallstreet Programmer
"...otherwise the view will directly bind to the properties of your model...."=> this is strictly recommended not to do in the MVVM pattern!
msfanboy
I thought you asked for a better method than strictly following MVVM. Pure MVVM will lead to problems with code maintenance since you need so much code just to copy state between model and VM. Also MVVM apps will have high memory consumption since data is duplicated.
Wallstreet Programmer
well you know what I did right now?Actually I was so glad that I managed a 3-Level Master-Detail in my view with 3 aggregated viewmodels and MVVM and I realized it was all for learning but not for practical use...so much overhead and all replicated properties and often my ...how can I name that lets say code flow ... is broken when I try to follow mvvm.Now I have just a ViewModel bound to the UserControls datacontext containing 3 aggregated entities not viewmodels what saves much time no converting forth/back properties and Lists...
msfanboy