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.
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
WCF's data objects should ideally be light-weight data transfer objects only. I would only re-use WCF's data objects if:
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.