ASP.NET Application on 3 physical tiers

Question

For clarity when I mention tiers in my question, I am referring to physical tiers (i.e. different servers for presentation, application and database)

My company has a public facing website that is currently built as a typical 2 tier system (web server and database server).

Soon a project will start in which we will be re-writing the whole site. We are required to split the project across 3 physical tiers. Actually, when you consider the browser then you could consider it 4 physical tiers.

In my experience most asp.net applications are built on 2 tiers. The web application itself my have several layers but physically it is deployed to two servers (web and DB).

I have searched for examples but it seems that layers and tiers get confused. I see a lot of multi-layer examples but no multi-tier examples.

In a nutshell it would seem that the web application makes web service or WCF calls to the application layer that marshals data to and from the database using ADO (or L2S or EF).

Does ASP.MVC help achieve this? Does it make it any easier or just different?

Is there a good reference or example of this somewhere?

Answer 1

This is an odd requirement. Did it come from the customer? It is possible that some customer education is needed.

I know J2EE systems can be split over three tiers, with web server on the first application server in the middle and a DB on the back end but I havn't heard of this with .NET.

Answer 2

In my opinion ASP.NET MVC isn't going to help, or hinder this scenario. Basically you'd going to have your model exposed not as Linq2Sql, the Entity Framework or any other ORM but from the middle tier, probably by WCF.

This presents the usual challenge around authentication and authorization - namely how does authentication flow between tiers., but that's are unique to MVC, a WebForms solution would have the same sticking points You'll also lose the model validation bits that an ORM may supply and will have to provide that yourself in your web services repository, but that's just a matter of implementing the right interfaces.

Answer 3

Gday Rick,

I work for a company that has the same multi tiered policy due to security.

I have an ASP.NET MVC web application on one tier that connects to a application tier that a web service sits on and is basically a facade for the database and a mainframe. Pretty much exactly the same as your setup.

ASP.NET MVC makes it really nice and easy to use this setup because you can easily build a validated object model in your ASP.NET MVC application. Once the object passes all top end validation you can easily transfer it on to the application tier via a web service.

I suppose this would be easy to do with a classic ASP.NET application however I think MVC makes things a lot easier!

Check out my blog for an example of how I have validated my models before sending to the application server.

Cheers, Michael

Answer 4

I don't think adding another tier increases security, but it definitely slows down performance and significantly increases development cost and complexity.

In the end, you can partition your application with an additional tier anyway you want. If it were me, I'd probably create the dumbest pass through tier I could if I was given this "interesting" requirement.

In fact, managing security around another tier implies significantly increased opportunities for security holes to be accidently exposed.

ASP.NET MVC should have no impact, but you will likely end up using something like WCF. For marshalling data back and forth, you probably want to use DTOs which are not tied to any particular database or ORM.

This is not a situation I'd be happy to find myself in. Increased complexity does not lead to increased security.

Answer 5

As mentioned before... MVC won't really matter in this situation. The closes analogue I have is we had a financial client separate out their web services into tiers...

so something like 1) public facing load balanced web services 2) web services 3) application code 4) database code

I don't remember if layer 3 and 2 were physically separated (been a while) but essentially layer one was fairly thin and just threw the requests over the dmz to the inside service.

So you could probably do something similar with the web site... potential for bottlenecks, but would get you the physical separation you need.

Good Luck!