16

Moving from the traditional way of architecting web applications with a Business Layer, Service Layer, Data Access Layer and a Presentation Layer to the MVC design pattern, I find it difficult to understand how it fits in the old model.

It seems to be that the MVC model itself already has done allot of the separation of concerns that is needed and used to be achieved via a layered architecture. Can someone shed some light on this subject please?

As a reference, below is how I understand it, please share your view on this

MVC Views and Controllers along with View Models -are- Presentation Layer

MVC Models - could be - Data Access Layer or Business Layer or even Service Layer

Max
  • 163
  • 2
  • 7
  • 1
    possible duplicate of [How MVC (ASP.NET MVC) band 3-tier architecture can work together?](http://stackoverflow.com/questions/3047230/how-mvc-asp-net-mvc-band-3-tier-architecture-can-work-together) – jgauffin May 13 '11 at 11:17
  • 2
    This is not a duplicate as the other post discussed the 3-tier architecture more from a physical sepration poit of view and not a conceptual sepration. – Max May 13 '11 at 15:12

4 Answers4

36

I see the Asp.Net MVC part only as the view (or presentation) part of the whole application.

I struggled too with the problem how to structure the app in a proper way.
Following the Onion Architecture I heard about here (and especially the image found here), my solution looks this way:

  • Project.Core
    Business logic/services implementations, entities, interfaces that must be implemented by the other projects (i.e. "IRepository", "IAuthenticationService",...)
  • Project.Data
    DB connection - in my case NHibernate repositories and entity-mappings go here. Implements data-interfaces of Project.Core
  • Project.UI.Web
    The Asp.Net MVC ("presentation") project - it wires the whole app together.
    Has implementations for Interfaces in Project.Core and wires them (and those from Project.Data) up with some DI framework like Castle Windsor.

Project.UI.Web follows the following conventions:

  • its models are only(!) viewmodels
  • the views consume their own viewmodel (one-view-one-viewmodel)
  • the controllers just need to validate the input, transforms it into domain objects (as the business logic knows exacly nothing about viewmodels) and delegate the real work (business logic) to the business services.

Summary:
If you follow this model it's helpful to focus on Project.Core: that is the real application. It doesn't worry about the real persistence of data nor cares about how does it get presented. It's just about "how-to-do-it". But it's laying out the rules and contracts (interfaces) the other projects must provide implementations for.

I hope this helps you with how to layout an Asp.Net MVC application!

Lg
warappa

Leniel Maccaferri
  • 100,159
  • 46
  • 371
  • 480
David Rettenbacher
  • 5,088
  • 2
  • 36
  • 45
  • 1
    I don't understand how service implementation comes in the core. Should it not be outside of Project.Core? That way you prevent accidentally tight coupling to the svc instead of svc interface. – Narayana Dec 10 '13 at 07:50
  • In your Project.UI.Web, what is an example of the Interfaces from Project.Core that you have implementation for? – variable Jul 01 '21 at 12:59
3

As others have said, it doesn't change much. My apps are typically architected as such:

  • Model Layer (Domain and View Models)
  • Repository Layer (data access)
  • Service Layer (sometimes implemented as WCF services depending on the app/requirements)
  • Server side MVC Layer (Asp.net MVC itself)
  • Client side MVVM or MVC (via either Knockout.js, Backbone.js, or Spine.js)

In the server side MVC layer, my controller methods are very light. They typically call a method on a service layer object to get some data and pass it along to the client as Json data.

Because I'm sending Json back, my views are also very light and sparse. Typically just containing script includes and templates which will be rendered with a client side templating library.

Craig M
  • 5,598
  • 4
  • 32
  • 43
0

In short: nothing much changes.

I'm only familiar with a few presentation patterns: MVP (Model, View, Presenter, common in windows forms/asp.net), MVC (Model, View, Controller) and MVVM (Model, View, View Model, commonly used in WPF/Silverlight).

Link: http://haacked.com/archive/2008/06/16/everything-you-wanted-to-know-about-mvc-and-mvp-but.aspx

Above link should answer some (if not all) of your questions.

The way I usually write ASP.NET MVC applications is by including at least a Service/Business layer hybrid for CRUD operations (because data access belongs neither on the view model or controller and definitely not in the view!).

Schalk
  • 316
  • 2
  • 3
  • What if you use the enitiy framework? It does give you an abstraction in form of a set of easly managable MVC data models. Do you then need an aditional data access layer? – Max May 13 '11 at 15:22
  • Something like Automapper can be used to map EF's entities to your domain models. I recommend keeping domain models out of the MVC model namespace and put them in their own assembly. – Craig M May 13 '11 at 17:12
-2

Very basic explanation:

If you create a new MVC application you will automatically get a Controllers, Models and Views folder.

Your controllers act like your Business Layer
Models are Data Access/Service layer
and Views are the presentation layer.

See http://www.asp.net/mvc for a fully detailed explanation.

Matthias
  • 12,704
  • 13
  • 35
  • 56
  • 14
    Controllers are not the Business Layer. In fact, the controllers should be as thin as possible – psousa May 13 '11 at 11:12
  • 2
    I'm with @psousa on this one, in fact microsoft recommends not having any business logic at all in the controllers and handle that all in the models. – Max May 13 '11 at 15:16