CODEWITHSUNDEEP
asp.net-mvcn-tier-architecture
Robert Koritnik
Robert Koritnik

Reputation: 105081

Does Asp.net MVC help creating n-tier solutions?

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?

Upvotes: 1

Views: 1418

Answers (6)

Matthew Groves
Matthew Groves

Reputation: 26169

"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

Upvotes: 0

fretje
fretje

Reputation: 8382

Off course it does!

I think both views and controllers contain user interface logic... the business logic should be in the model (which is not only the DAL).

As the model you could use e.g. CSLA objects and add another couple of physical layers as needed (through configuration).

You have to know there's a difference between logical and physical layers (or layers vs tiers)...

There are a lot of interesting articles on lhotka's site regarding this topic!
E.g. this one and this one.

Upvotes: 2

dso
dso

Reputation: 9580

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

Upvotes: 3

aleemb
aleemb

Reputation: 32105

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.

Upvotes: 0

Tomas Aschan
Tomas Aschan

Reputation: 60674

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.

Upvotes: 4

Spencer Ruport
Spencer Ruport

Reputation: 35117

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

Upvotes: 2

Related Questions