Correct definition and design of business, domain and view models in a MVC layered application

Question

I have an ASP.NET MVC3 in C# and Razor. The architecture of the application is divided in Data Access Layer (EF classes + Repository), Service Layer, Controller, ViewModels and View.

My application is a dashboard, it has to display statistics about products by using graphs.

Assume I have Product and ProductCategory tables and in a graph I have to display the percentage of sold Products per ProductCategory per Month. In the x-axis I have the months, in the y-axis the percentage ProductPerCategory/ProductTotal and therefore I have as many lines as ProductCategories.

In this case my Domain Model is made by Product and ProductCategory objects on the EF. My repository gives these domain objects to its upper layer (Service Layer).

My Business Model is made by the ProductGraph object and my Service Layer gives this business object to its upper layer (Controller).

My controller take this ProductGraphobject and map it to the View Model ProductGraphViewModel to be displayed in the view.

Is this distinction between models correct? Is there any shortfall or bad approach on the definition of the objects passed between layers?

Answer 1

I'll answer your question by asking a few of my own.

1. What is your distinction between "Domain Model" and "Business Model"? Do each give more/less value than the other? Without knowing more, i would assume they are the same thing.

2. What benefit does your Service layer give? People (myself included) have often fallen into the "Service layer" trap, when in fact it just wraps your Repository methods. You end up leaking ORM specifics to consuming layers, defeating the point of your abstraction in the first place.

It might help if you give us some code of an example flow between the layers.

And yes, @sweaver2112 is spot on about using DI. Simple setup, maximum benefit.

Answer 2

Well, you have my layman's thumbs up, this seems pretty standard. Some other things to consider are: 1) is your DAL/Service Layer interfaced? and 2) are you using dependency injection (passing these interfaces to the controller instantiation)? That way you can switch out implementations, or mock for unit tests easily.

This blog post might be of interest.