MVC and MVVM with WPF

In any MVC pattern, there is no argument about the definition of the view. View is the user interface that user interact with the software system. In classic window app, it is the Window form, and controls. In classic ASP.Net app, it is the ASPX page. In MVC.Net it is the ASPX page made up by HTML and other tags.

In WPF app, it is the XAML file. In another word, it is the UI.

It is commonly accepted that UI layer should be free of business logic, including user process logic.

So what is Model?  Model is not only Business Entity object model. It is the business logic of the system. In a typical 3 tier architectural system, most of business logic should be implemented in the service layer.  Then the question left unanswered is “then what is the rest?” In general term we call it user process logic. In MVC pattern, it is the controller, in MVP pattern, it is the Presenter. In MVVM pattern, it is the ViewModel.

Through service proxy, the business object model, business service (in WCF world, they are represented by data contract and service contract) are made available as part of model. The rest of the model is the user interaction logic or user process logic.

It is commonly acceptable that it is our goal to make User Interface Process (UIP) logic agnostic of UI platform and independent of View. This is so for many reasons. Reusability is one of them, testability is another.

Within MS platform, there are 2 types of application, window app and web app.

Before MVC.ASP.Net for Web, WPF for window, all we can do is to minimalize such dependency we could not totally eliminate it.  In either classic ASP.Net or classic window form, there is no way to totally eliminate code-behind logic. And these left over at the code behind are most likely the user interface process (UIP) logic.  Any code that dependents on the UI elements would be regarded as dependent of UI elements.

Thanks to two-way binding provided by XAML. With XAML, we finally are able to achieve the goal of making UIP logic independent of View.  The bridge between the back end service and UI is ViewModel. The bridge between the View and ViewModel is two-way binding

From component reference point of view, UI (View authored in XAML) reference ViewModel, ViewModel reference the model provided by the backend service through proxy.

Between View and ViewModel there are 2 ways to guaranty the reference is single direction. The first way is to make them in separate components and make the UI reference the ViewModel. In this way, ViewModel is forced to have no knowledge of the View.

Another way is to ensure that all the UI element in XAML have no id, no name. So that ViewModel has no way to reference them.  In both cases, make sure we do not have code behind the UI elements written in XAML.

The 2 success factors in WPF MVVM application are 1) correctly employ of the pattern. Another is XAML authoring. One could use both Visual Studio and Expression Blend to author the UI.

For the rest of this article, I am going to focus on ViewModel aspect of MVVM.  However, I would like mention that there is lack of study material on XAML authoring and it is hard to find some good XAML design guys in the market.

With Reference to ViewModel, the UI designer could design UX with dummy data in design model within either Visual Studio or Expression. However, Expression Blend is more designer friendly while Visual Studio is more developer friendly.

The wonderful news is that with WPF + MVVM, designers and developers can work on the same codebase using the tools they are familiar with.