I’m new to MVVM. Currently I’m developing a WPF project in C# that will have a SQl Server backend and I’ll be using a standard WCF service to communicate with it. All the tutorials I’ve seen on MVVM thus far always seem to use some static data repository such as an xml file for their backend. I haven’t yet seen implemenations using a database and a data access layer, so I’m confused as to where my WCF service fits in. The service has all data objects defined in it, so does the service itself then become the model? In addition, how do I go about including the service in the ViewModel so that the designer doesn’t throw an error stating that it cannot create an instance f the service class? Any help here would be greatly appreciated as I find it strange that so many tutorials on this subject omit the most prctical implementation for a line-of-business application.
PS I would like to steer clear of WCF RIA services and Silverlight as the Silverlight’s lack of support for commands makes the book I’m following (Pro WPF and Silverlight MVVM Effective Application Development with Model-View-ViewModel) difficult to understand.
OK, I’ll try to get you up to speed …
First, I do recognize the question about the model and the object model exposed with WCF. Are they the same? Well, I would like to make that assumption currently, for sake of simplicity. So then we do not need the model part of MVVM on the client side? Depends …
The ViewModel is in the driving seat. We let it create the client proxy to your WCF service. The objects used in the request and returned as result makes your model. Anything you want to cache on the client side or is not directly bindable with the UI will be put in properties in your model container class. Generate bindable properties from these model properties for consumption in your UI. Every else will just be direct properties in your view model.
About WCF and the data access layer, there are a few important thing to recognize. First of all, you will need to have a seperation between you logical (information) model and your physical (database) model. One reason is to abstract your database technology away from your application. Another to allow small deviations between your application / domain logic and your physical implementation. Make sure your (entity) model classes are generic enough to support changes in your UI without having to modify the complete application stack for every UI change.
It is hard to talk about this matter without a clear example, so to wrap up I would like to invite you to look at http://aviadezra.blogspot.com/2010/10/silverlight-mvvm-odata-wcf-data.html. I know, it IS using WCF data services and SilverLight. Don’t be mad at me directly for directing to this sample and give me the thumb down. It is just such a damn good example of what you want to achieve and what to introduce and what to think about setting up such an application. Just replace Silverlight by WPF and Data Services by regular typed data contracts and the rest of the story will help to get your thoughts clear.
Hope it helps you in your quest!