WPF MVVM Architecture in Layered Enterprise Application

Question

I am new to WPF and MVVM. This is how I generally set up my architecture for ASP.net applications:

Data Layer

I generally use an ORM tool to persist data to the database.

Business Layer

This includes all my business models and business logic.

Service Layer

This layer is used as an entry point into the back end system. (Sometimes via WCF). This layer is responsible for converting business models into View Models.

Presentation Layer

This layer is used for presentation logic.

---

I am aware that the View of the MVVM is the .XAML file and resides in the WPF Application. However I am a little bit confused about the "Model" and "ViewModel" as I already have a "Model" in my business layer and a "ViewModel" in my ServiceLayer. I could just use these however that would mean that my Service Layer would be tied to a specific implementation since it will need to include: RelayCommand, Oberservable Objects etc.

What is the recommended approach to this problem? Am I missing something? Should there be another layer of abstraction so that the Presentation layer (WPF) includes the "View" the "ViewModel" and the "Model"???

Answer 1

A more proper name for MVVM would be View - ViewModel - Model since that would express how they are actually layered. The ViewModel serves the purpose of adapting your Model to the View. This is accomplished through binding properties.

The only thing the View needs to know about the ViewModel is which properties it exposes. The ViewModel does not need to know anything about the View. They communicate through those ViewModel properties by means of INotifyPropertyChanged, based on how you configure the binding (so a property value flows from the ViewModel to the View, viceversa, or both).

The other common way of communication between them are Commands which are invoked by the interface in response to some user action (typical example, button press). The View can also invoke Commands through binding and the ViewModel can register handlers to react to Command invocations.

By reacting to both Commands and PropertyChanged events, your ViewModel can act as a controller for your model. How you access your model depends on your design, you may use a service layer that does not need to know anything about your ViewModel, Commands, properties or what not. Your ViewModel simply interacts with it on response to user actions and updates its own properties to notify the View of the results.

Note that the model exposed by your service layer does not need to be the same used internally in your business layer. For instance, your service layer may use DTOs to communicate with the ViewModel, and the DTOs can be significally different from your business model objects.

This is just a quick overall picture of a possible layered architecture for WPF, there are many more options, patterns and tools at your disposal. (Probably as many as better explanations than this you'll find by searching for MVVM.)

Edit answering comment question

So you're basically saying the "View" and the "ViewModel" should be in the WPF project and the "Model" is essentially what is passed from the service layer?

Yes, View and ViewModel usually reside in the same project. A typical setup is creating View and ViewModel folders, and having a ViewModel for each one of your Views - or even in the very same folder.

In large projects Views and ViewModels may reside in different assemblies. As stated before, ViewModels are independent of the Views binding to them: there is no need for them to know details about the View and this is what makes them so test-friendly. However, since they work together very closely it is very common to design your ViewModels along with the View (and its requirements) thus having a high degree of coupling that makes their reuse highly unlikely (hence, their ending up in the same assembly).

Answer 2

MVVM in the case of a web application play the role just on the client. The model are the data in the plain format (maybe JSON) structures as they comes from the server, the view model are the data you actually bound to the presentation, and where you collect user modifications. The view of course is the web page itself. You probably want to study some libraries as Backbone to better clarify the concept.