Should I use DTOs as my data models in MVVM?

Posted by JonC on Stack Overflow See other posts from Stack Overflow or by JonC
Published on 2010-04-27T10:21:41Z Indexed on 2010/04/27 10:23 UTC
Read the original article Hit count: 282

Filed under:
|
|
|

I'm currently working on what will be my first real foray into using MVVM and have been reading various articles on how best to implement it.

My current thoughts are to use my data models effectively as data transfer objects, make them serializable and have them exist on both the client and server sides. It seems like a logical step given that both object types are really just collections of property getters and setters and another layer in between seems like complete overkill.

Obviously there would be issues with INotifyPropertyChanged not working correctly on the server side as there is no ViewModel to which to communicate, but as long as we are careful about constructing our proper domain model objects from data models in the service layer and not dealing the the data models on the server side I don't think it should be a big issue.

I haven't found too much info about this approach in my reading, so I would like to know if this is a pretty standard thing, is this just assumed to be the de facto way of doing MVVM in a multi-tier environment? If I've got completely the wrong idea about things then thoughts on other approaches would be appreciated too.

© Stack Overflow or respective owner

Related posts about wpf

Related posts about mvvm