views:

687

answers:

6

My opinion is it does and it doesn't.

  1. It does separate logic and data from UI, but it still crams it all together into a single point application.
  2. That's why I think it doesn't really, because Controllers are business logic, Views are UI, Models are DAL. These are now just layers within the same app.

But are layers supposed to be the first or the second variety to be actually called layers?

Anyone wants to add their own 2 cents?

+2  A: 

Well, my birthday cake had layers but it was still one big cake... so yes?

Spencer Ruport
+4  A: 

The MVC template project is just to get you started - you can easily move the Controllers and/or Models out to separate projects if you want to, and if it makes sense in your application. Remember, that for a small app with maybe three controllers, a couple of extra classes in the Models layer plus an EF or LINQ data model, you really don't have enough files to justify separation into different projects.

Tomas Lycken
+1  A: 
fretje
A: 

Layers and tiers are interchangeable. In context of an n-tier you'd call it a presentation tier but in context of a layered application you'd call it a presentation layer. But really they are the same thing.

A litmus test of n-tier application and loose coupling would be if you can take each of the tiers and build them as separate projects and deploy them on different machines.

The key differentiator for n-tier applications is Separation of Concerns (SoC) and low coupling. A truly decoupled application might be one where you have a tier that contains nothing but pure HTML. Then another which contains pure Javascript and uses AJAX to update the DOM and communicate with the web service. The web service comprises it's own set of tiers.

The web service has a routing engine that routes the requests to the different controllers. The controllers sanitize and interpret the request, verify authentication and what not and call the appropriate models. the models in turn must return POCO objects or DTOs and return these to the Javascript which injects them into the DOM. The Javascript may modify the objects and send them back to be persisted into the database. Entity Framework 4.0 has good support for just such n-tier scenarios though it does fall a bit short in the SoC department (strongly types views for example) but it's practical for more purposes.

MVC Futures I believe has support for some Inversion of Control (IoC) containers out of the box and currently if you want loose coupling and truly n-tier scenarios you will probably need to use an IoC container of your choosing.

aleemb
+2  A: 

I don't think of Controllers as business logic. They are application logic, the glue which ties together the business logic (Model) and the presentation logic (View).

DSO
don't you think that business logic (as in business processes) is *not* part of the model? Model is merely a data store for business processes...
Robert Koritnik
But you are right about Controllers. They are not the actual Business process logic. They just serve them. I think there should be a separate part: "Processes" that would glue Controllers and Model into an actual Business layer.
Robert Koritnik
A: 

"Tier" usually refers to different physical servers, while "layers" refers to separation of functionality into loosely coupled areas.

That is, a 3-tier web application: Tier 1) DB Server Tier 2) Web Server Tier 3) Client browser

3-layer web application: Layer 1) UI Layer 2) Business Logic Layer 3) Data Access

mgroves
I don't know if that really answers the question, other than: "you can write FORTRAN in any language", but yeah MVC kinda nudges you in the right direction.
mgroves
@mgroves: I think it's very relevant to this question, as apparently the questioner is mixing the two terms up. (see also my answer and the links regarding this topic)
fretje