Layered Model-View-ViewModel design

Question

I am designing an application using C# and Windows Presentation Foundation (WPF). I would like to follow (at least) the very basic rules of software architecture, like dependicies only going in one direction. Also I would like the UI layer to be without any sort of business logic (i.e. the application should work even without the user interface).

I have tried to draw my current thoughts, but I am already struggling with the data layer, as I would prefer not to build a data access layer on top of Entity Framework (the likelyhood of changing data access method in the applications life span is really small).

As I said, I am aware of violating the direction rule, with the connection from Service to DbContext. I just haven't figured out how to go about it (maybe let the BLL consume the DAL?).

But here are the general ideas:

• The DisplayModel is similar to a ViewModel, but must be completely dumb (sort of a DTO). And it will not have its own view. It could be used for instance, as list items. It might implement INotifyPropertyChanged.
• The ViewModel will get entities from the Service and convert them to DisplayModels using AutoMapper.
• The Model is a shared interface, ensuring that the naming of properties are identical in the DisplayModel and Entity (makes it simpler to use AutoMapper).

Is this a good way to do things or am I walking into a trap with this homemade design?

I have read quite a bit about MVVM and layered architecture. This reading has been the foundation of my design. However, I have not been able to find an actual complete design patter for MVVM and WPF.

Answer 1

This looks properly strange to me. Normally, in MVVM, the only thing in your UI layer is xaml. Your View Models must not depend on your UI, so logically, they are a different layer (the reason for this is testability of your application independent of the UI, which is a very, very desirable attribute). There is not necessarily a 1-to-1 correspondence between each piece of UI and each view model, but it makes sense to do this.

All features of your application should be capable of running without view-specific concerns, so your domain model is logically a different layer too, regardless of how you enforce that.

In order to maintain unit-testability, you're also going to want to be able to instantiate versions of all the code in your business logic layer without reference to storage, so don't draw any arrows going out of the business logic layer.

Normally, your domain model layer is your business logic layer - if a separation is necessary (i.e. there is are abstracted data model objects from a layer that cannot or should not be modified based on the operations of the program - not the case if you have ownership of everything), then the domain model layer will own (usually abstracted) versions of the necessary objects, as per the direction of dependency you've drawn.

Nothing in the business logic layer should depend in any way on your storage technology - you're just asking for trouble completely unnecessarily.

What is the "service" box?

Correctly, your view model should only depend on your domain model.

Answer 2

It appears that you are over-complicating the MVVM design approach. That's a lot of classes to maintain there. I recommend you simplify it this way:

• Your model is either a POCO, or at most it implements INotifyPropertyChanged
• Get rid of the whole DisplayModel concept. It provides no value and complicates your implementation.
• Your ViewModel<T> would provide a reference to your model. If it implements INotifyPropertyChanged, you can even bind directly to the properties on it.
• Your View is simply the XAML view that binds to the ViewModel.

As far as notions of how you store and retrieve data, the conceptual load stops at the service layer. I am aware that many projects have a "repository" concept for the service, which helps put some structure around it. However, at the boundaries any notion of the internal mechanics are completely hidden from the rest of the system.

The whole DbContext and Entity concept are outside of the scope of MVVM. That's simply implementation details for how the service stores and retrieves data. It could just as easily be a wrapper around calls to a web service.