How ASP .NET MVC architecture fits into the tradit

问题:

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

回答1:

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

回答2:

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.

回答3:

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!).

回答4:

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.