We're working on a major re-write of a legacy VB6 app, into a WPF app. I've written several WCF services, which are meant to be used with the new WPF app. We want to use the MVVM design pattern to do this, but we don't have experience at that. So, in order to learn MVVM we've watched a video on WindowsClient called How Do I: Build Data-driven WPF Application using the MVVM pattern. This is a great introduction, and we refer to it a lot, but for our situation it doesn't quite give us enough. For example, we're not certain how to use datasets returned by my WCF services in our new WPF app using the ideas that Todd Miranda introduced in the video I referenced. If we did as we think we're supposed to do, then we should design a class that is exactly like the class of data returned in my WCF service. But we're wondering, why do that, when the WCF service already has such a class? And yet, the class in the WPF app has to at least implement the INotifyPropertyChanged interface. So, we're not sure what to do.
WCF's data objects should ideally be light-weight data transfer objects only. I would only re-use WCF's data objects if:
- My Models are always going to be simple POCO objects. No validation, no business logic, no property change notification, etc
- I don't care that the entire class as visible and fully accessible to whoever used it (You can't have read-only properties in a WCF data model)
- My View does not bind directly to the Model, and instead binds to ViewModel properties which expose Model properties. This is the "MVVM-purist" approach, however if it often more trouble to implement than it is worth, so binding your View to your Model is also acceptable
That being said, I have never actually used WCF data objects as my Models. Usually I create Model objects separately, and my client-side data access layer converts the WCF data objects into Models for my application to use.
I usually use something Automapper for this, which will automatically map data from one class to another, providing the names and types are the same.