Understanding 3-Tier vs. 3-Layer Architecture

The terms tier and layer are frequently used interchangeably, but actually there is a difference between them: Tiers indicate a physical separation of components, which may mean different assemblies such as DLL, EXE etc on the same server or multiple servers; but layers refers to a logical separation of components, such as having distinct namespaces and classes for the Database Access Layer (DAL), Business Logic Layer (BLL) and User Interface Layer (UIL). Therefore, tier is about physical separation and units of deployment, and layers are about logical separation and units of design.

Creating a multi tier project design is more suitable and advisable to mid to large-size projects, whereas a good multi-layered design is suitable for small to mid-size projects.

Let’s understand this difference more closely with my earlier posts on “Developing 3 Tier Application in .NET 2.0”. In reality this example is 3-layer architecture because all the layers are logically separated but stay in one code. Following are the namespaces of each layer

1. Vishwa.Example.Data
2. Vishwa.Example.Business
3. Vishwa.Example.WebSite1

The final DLL contains all the above layers: Vishwa.Example.WebSite1

Now, let’s think how to build the same project in true 3-tier architecture. For simple understanding, each layer will be moved to a separate project and thus creating following three dlls. These dlls can stay on the same machine or different servers.

1. Vishwa.Example.Data.dll     --- see  Data Transfer Objects (DTO) - Data Access Layer
2. Vishwa.Example.Business.dll --- see Data Transfer Objects (DTO) - Business Layer
3. Vishwa.Example.WebSite1.dll  -- Now you can refer the above new dlls to perform the same operation

But, by just moving the code of each layer into a separate project will not work, because first and foremost issue is: each layer depends on other layer, so you can not compile one project without other one and here you are in catch 22 situation.

So you will require changes into current design. Also, if you are not planning to keep all the layers in the same folder of your application, then another big issue- how to refer and communicate with each layer’s object. Here is some approach you can take for each layer to convert into a tier model.

• Literally, create a separate project for each layer.
• For Database Access Layer and Business Logic Layer ASP.NET Web Services or .NET Remoting can be used. If you can use .NET 3.0 Windows Communication Foundation (WCF) Services, that will be great, they seem to me like Web Services but more powerful, secure and flexible than Web Services.
• User Interface Layer will stay as ASP.NET Web Site but some changes will be required for invoking or calling Business Objects. However, existing BLL and DAL layers will be removed from current project.
• Additionally, I will recommend using Microsoft Enterprise Library - Application Blocks for .NET 2.0. This library can help you to build a robust application, it provides solutions to common development challenges such as data access, logging and user interface etc. You can find more information at http://msdn.microsoft.com/practices
• By using (Web) Services, you will move one step towards Service Oriented Architecture (SOA), which is becoming more popular now in enterprise application development.

You must be wondering why did I use the word 3-Tier instead of 3-layer?

First of all most of the time people are searching on key words like 3-Tier rather 3-Layer. Word 3-tier architecture is most frequently used but heavily misused in IT industry. So it is easier to bring people to the information they are looking for and then educate them as what exactly it means.

Needless to say that it was easier for me to take a simple example for 3- layer architecture design and explain each layer step by step. Developing a true multi tier approach may look like over killing of the sample project. I may write one sometime in future:).