3-tier web applications

Dec 16, 2007

Very often I read that you need to structure your web applications into multiple tiers to separate the concerns. The advice is to move the business and data logic out of the web project into two different projects so you end up with the classic 3 tier model – presentation, business and data. This advice is good.

The strange thing is that this advice is given to web developers as a way of structuring web applications. I’ve always found that very odd. Not that web developers don’t write business and data logic, but I don’t see the connection between web development and business/data logic development.

Let me explain

The premise for the advice is that business/data logic is part of building a website. This is wrong. A website is a visual representation that interacts with the business logic, but the business logic doesn’t and shouldn’t care about the website. The business logic is an API consumed by the website and nothing more. The business logic still doesn’t care if its public methods (API) are used on a website, in a Windows Forms application or in a web service. Ergo, business logic is not part of building a website. The premise is wrong.

In a typical 3 tier web solution you have three projects – the website, business- and data logic projects. That makes it a little confusing to believe that the business and data logic has nothing to do with building a website. But if you think of the three projects as the building blocks in creating a solution then it’s easier to understand. In other words; you don’t separate a website into three tiers by separating the business and data logic into their own projects, you separate the solution into three tiers. Since the website is just the UI in such a solution, it is wrong statement that your website is 3-tiered and the premise is then wrong.

The three tiers

The reason why I’ve always found this advice odd is that I always build my websites in three tiers, but it has nothing to do with the business and data logic. The three tiers I use in web development are specific for the website only. The tiers are:

  1. User interface
  2. User interface logic
  3. Presentation logic

The names are just some that I use and may be different elsewhere.

User interface (UI)

The UI is the HTML, JavaScript and CSS that makes up the visual look and feel and the browser behavior. It lives in pages (.aspx), user controls (.ascx), .js and .css files. In some cases also in HTTP handlers (.ashx), but mainly for custom AJAX mechanisms.

User interface logic

This tier is what controls the server side behaviour of the UI. It lives in code-behind files and in the App_Code folder. This logic is responsible for handling button events and differentiates the response based on the user etc. It’s also custom web control collections that could live in its own project and often do.

Presentation logic

This is the where all the stuff goes that isn’t directly is used in the UI. It could be RSS feeds or classes used by the code-behind. Most often it’s where I put the HttpHandlers and HttpModules and the logic that controls them. It could be located in its own project or it could just be in its own folder in the App_Code or wherever it feels right to put it depending on the size of the project.

It doesn’t really matter where the tiers are physically placed as long as they are logically separated. That’s why it often makes sense to move the tiers into their own projects to make the separation clear and the code easier to maintain and reuse.

So a three tier web application has nothing to do with business and data logic. Remember that the business logic is just an API consumed by a website even if they both live in the same Visual Studio solution.

* Only $4.95/month ASP.NET & Windows 2008 + IIS 7 Hosting! FREE SQL Included

Comments (11) -

Joe
Joe United States
12/17/2007 12:10:18 AM #

Good to see another dev shared my opinion

Jacques Philip
Jacques Philip United States
12/17/2007 1:08:58 AM #

User interface (UI) : Views
User interface logic : Controllers
Presentation logic : Helpers

This is why BlogEngine.net is such a nice ASP.NET project

Dan Atkinson
Dan Atkinson United Kingdom
12/17/2007 8:40:52 AM #

I'm interested to know where the 'advice' was garnered that finally made you snap and write this article. Smile

Mads Kristensen
Mads Kristensen Denmark
12/17/2007 8:52:07 AM #

@Dan, I don't remember any specific post that ticked it off. It's probably those best practices lists you see floating around.

Tom
Tom United States
12/17/2007 1:13:07 PM #

I’ve actually never heard of people making three separate projects just to separate their tiers before so that was new to me.  I’ve worked on big projects where it was necessary to separate concerns but generally there were more than three separations in those projects and it wasn’t done solely to fit into some 3-tier criteria.

Beyond that though I think a lot of programmers still choose to (for better or worse) put a certain level of abstraction in their code which is what accounts for them defining  their middle tier as a business layer.  So while the business layer may just be an API consumed by the web site it may contain a lot of classes representing data abstractions that the programmer thinks makes the code more understandable and logically outlined.  

I tend to fall in the middle here in that I consider the tier system more of a metaphor in my head that I use to group different classes.  So I’ll have SQL stored procedures and a GenericDataAccess class that I consider the Data tier and then everything that is actually code only (a.k.a.  essentially your UI logic tier and Presentation Logic tier) I consider the business tier.  

I mean, it’s hard to do in a web based application because the waters are clearly a little muddy especially with Javascript and CSS taking care of some actual functionality making it impossible to have a strict tier system but I find it helps me keep things straight in my head.

William
William United States
12/17/2007 2:38:56 PM #

Great article and several excellent points.  However, around 1997-2001 (possibly prior to 97), many organizations were grappling with how deep a web application interacted with the data.  At the time, because web based interactivity was still fairly novel, it was not uncommon for a web based application to be all encompassing.  API interaction, if required or available, was often being developed by the web and COM developers.  Maybe the advice is a legacy of that time?

It's amazing to see how fast things have changed and to think that comparatively, we're still only at the beginning.

Mads Kristensen
Mads Kristensen Denmark
12/17/2007 3:15:06 PM #

@Dan, now I remember where it was. It's coming from a lot of hype around the ASP.NET MVC framework.

John
John United Kingdom
12/17/2007 4:46:19 PM #

You article was interesting and well considered.

I'm wondering though, if this approach adds a burden of complexity that is unnecessary.

I've been developing applications for over 20 years and web applications for 12 of those. People are always coming up with new methodologies.

What I have learnt and always works for me is focus on the user. Your approach focuses too much on the development process. Focus instead on what the user needs. The process should be the servant and not the master.

If this methodology works for you, fine, and thank you for sharing it.

Miron
Miron Israel
12/18/2007 12:38:40 AM #

Your article is interesting. However,I can't say I completely agree with your opinion, but I also can't say I don't. You mention that 'you don’t separate a website into three tiers by separating the business and data logic into their own projects'. It's all about what you define 'website'. The business and the data logic will always be there, so you can consider them as part of your 'website' or not.
As we are all 'programmers' when we r building a 'website' we usually have to build the business and the data logic as part of the web development process - As separate projects, classes dropped in the App_Code or just one another 'Core' class library. But they are always there.
So, You can consider them as just an API that is not part of the website. I consider it a part of my 'website'. As long I have to write it.
All about how you see the world...
Wink
Always enjoy to read your posts.

Chicken
Chicken Poland
12/24/2007 5:55:28 AM #

And my opinion is a little bit in the middle. So I agree that business logic may be separated from the web application. Business logic is enclosed in it's own core project and let's say is accessible through BL Facade API.

On top of that business logic we can build different UIs or e.g. we can expose this logic with web services.

But ... if the UI is very complex maybe it's also good to separate it into more tiers. Let's say that the web site UI is personalizable - so user's details / preferences are kept in a separate DB. (It may be the same as for BL, but may be a completely different one) and let's say that this web app is consuming some web services. What I do is under those 3 layers described by Mads add another two -

web app's data access - to access DB , web services, Active Directory etc. (but only for information related to web app. Also to deal with the real business logic API

web app's business logic - responsible for conversion, validation, cause usually what you can get from data access layer is not what you can directly consume. This layer may be combined with Model (MVC pattern)

And then on the top of it View and Controller (Presenter).

So maybe it's a little bit more complex, but for me it's much easier to prepare unit tests, concerns are separated, and for me it just works great that way.

And as far as focusing on end-users point of view - of course we should all the time be concentrated on our clients, and such approach guarantees that by: improved testabillity, easier to manage code. And it does not have anything to do with the end-user requirements analysis, right. It's more about assuring the right quality and developing extensible solutions that conform to agreed specification.

Kåre Per Hansen
Kåre Per Hansen Denmark
1/29/2008 11:31:04 AM #

Here is how Microsoft patterns & practices define layers and components:

Application Architecture for .NET: Designing Applications and Services (see Chapter 2)
msdn2.microsoft.com/en-us/library/ms954595.aspx

BTW it is a very good guide to read.

Comments are closed

About the author

Mads Kristensen

Mads Kristensen
Program Manager at the Microsoft Web Platform team and founder of BlogEngine.NET.

More...

Month List

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer’s view in any way.