Introduction

This article describes how to build ASP.NET applications using n-tier architecture. The benefits of having n-tier architecture is that all the modules having dedicated functionality will be independent of each other. Changing one tier will not effect other tiers and there is no single point of failure even if some tier is not working.

Background

In a typical n-tier application there will be 4 Layers. The bottom most layer is the Data layer which contains the tables and stored procedures, scaler function, table values function. This Data layer is typically the database engine itself. We will be using SqlServer as the data layer in our example.

On top of Data Layer, we have a Data Access Layer (DAL). This layer is responsible for handling Database related tasks i.e. only data access. This Data access layer is created as a separate solution so that the changes in DAL only need the recompilation of DAL and not the complete website. The benefit of having this layer as a separate solution is that in case the database engine is changes we only need to change the DAL and the other areas of the website need not be changed and recompiled. Also the changes in other areas outside this solution will not demand for DAL recompilation.

On top of DAL, we have our Business Logic Layer(BLL). BLL contains all the calculations and Business Rule validations that are required in the application. It is also in a separate solution for the reason that if the Business rules change or the calculations change we only need to recompile the BLL and the other layers of the application will remain unaffected.

Finally on top of BLL we have our Presentation Layer. The Presentation layer for an ASP.NET web forms application is all the Forms (apsx pages and their code behinds) and the classes contained in the App_Code folder. The Presentation layer is responsible for taking the user input, showing the data to the user and mainly performing input data validation.

Note: Input data filtration and validation is typically done at the Presentation Layer(Both client side and server side). The business Rule validation will be done at the BLL.

So to visualize the above mentioned architecture:

Note: The Data Access Layer in this article was written using classic ADO.NET, due to which the amount of code in DAL is little too much. Nowadays using ORMs like Entity framework to generate the DAL is recommended. The DAL code will be generated by ORM itself.

Using the code

Let us develop a small Toy ASP.NET application that will use n-tier architecture. We will develop a small Employee Management application for the NorthWind Database. (For simplicity, I have removed all other tables from the DB and some columns from the Employee table). This application should be able to perform the basic CRUD operations on the DB.

The solution for this application will contain separate projects for DAL and BLL. The Data Layer will be SqlServer. The Presentation Layer is an ASP.NET website running on top of these projects.

The Data Layer

The data layer in this example contain only one table called Employee. The data layer also contains the stored procedures for all the basic operations on the Employee table. So let us look at the table and all the stored Procedures we have in our Data Layer.

Now we will create a set of stored procedures to perform the operations on the Employees Table.

The Data Access Layer

Now we will go ahead and create a Data Access Layer for our application. The data access layer will contain 2 main type of classes. A set of classes that will represent the Table entities. And classes to perform the CRUD operations on the database.

The Employee class in the above diagram is the Entity that will represent the Employee table. This class has been created so that the Layers above the DAL will use this class to perform operations in Employee table and they need not worry about the table schema related details.

Note: If we use any ORM(Object Relation Mapper) then DAL need not be written. The ORM will generate all the DAL code. Entity framework is one of the best ORMs available. This DAL can simply be replaced with a class library containing the Entity Framework generated Entities and Contexts.

The Business Logic Layer

The business logic layer will have a reference to the DAL and will mainly perform Business rule validation and business logic specific calculations. In out example, I will write a simple BLL that will govern the IO between the DAL and Presentation layer. In real applications the BLL will contain more logic and code.

publicclass EmployeeHandler
{
// Handle to the Employee DBAccess class
EmployeeDBAccess employeeDb = null;
public EmployeeHandler()
{
employeeDb = new EmployeeDBAccess();
}
// This fuction does not contain any business logic, it simply returns the // list of employees, we can put some logic here if neededpublic List<employee> GetEmployeeList()
{
return employeeDb.GetEmployeeList();
}
// This fuction does not contain any business logic, it simply returns the // list of employees, we can put some logic here if neededpublicbool UpdateEmployee(Employee employee)
{
return employeeDb.UpdateEmployee(employee);
}
// This fuction does not contain any business logic, it simply returns the // list of employees, we can put some logic here if neededpublic Employee GetEmployeeDetails(int empID)
{
return employeeDb.GetEmployeeDetails(empID);
}
// This fuction does not contain any business logic, it simply returns the // list of employees, we can put some logic here if neededpublicbool DeleteEmployee(int empID)
{
return employeeDb.DeleteEmployee(empID);
}
// This fuction does not contain any business logic, it simply returns the // list of employees, we can put some logic here if neededpublicbool AddNewEmployee(Employee employee)
{
return employeeDb.AddNewEmployee(employee);
}
}

The Presentation Layer

The presentation layer now contains only a set of pages and code behinds and it will use the BLL and the the Employee class to perform all the operations. The add Operation can be seen as an example how the BLL is being used to perform an operation.

Note: All the CRUD operations have been implemented. Please refer tio the sample code for all the details. When we run the application we can see all the EDIT/UPDATE, DELETE and ADD operations in action.

Point of Interest

I created this small application to demonstrate application development using n-tier architecture. The demo application has been created to show the basic idea behind the 3-tier architecture. There are many things that are still missing from this sample from the completion perspective. Client side validation and server side validation in presentation layer, Business rule validation and calculations in BLL are some missing things.

Since the idea here was to talk about how to put n-tier architecture in actual code, I think this article might have provided some useful information on that. I hope this has been informative.

[UPDATE] Note: In this article I am reusing the Employee model in the presentation layer. This model is defined in Data Access Layer. Due to this the presentation layer has to refer to the data access layer. This is not ideal in the real world scenarios(as pointed out in many of the comments below). Ideal solution for this would be to have two different models for Employee. the current model which is defined in the data access layer can be called as the data model and the business logic layer can create a model for employee which will be called as domain model. The business logic layer will then have to contain the code for mapping the data model to the domain model and vice versa. This mapping can be done either manually or a tool like AutoMapper can also be used to perform such mapping. With this change the presentation layer need not refer to the data access layer but it can refer to the business logic layer and use the Employee domain model from that.

In this article the n-tier architecture is specifically a data centric n-tier and not a domain centric one. If we need to design the application in a domain centric n-tier architecture then we need to follow a different way of organizing our layers. But perhaps that is a topic which deserves a separate discussion altogether but I wanted to point out the possibility of a domain centric n-tier architecture in this article.

Share

About the Author

I Started my Programming career with C++. Later got a chance to develop Windows Form applications using C#. Currently using C#, ASP.NET & ASP.NET MVC to create Information Systems, e-commerce/e-governance Portals and Data driven websites.

My interests involves Programming, Website development and Learning/Teaching subjects related to Computer Science/Information Systems. IMO, C# is the best programming language and I love working with C# and other Microsoft Technologies.

My question is how to design n-tire architecture when we have multiple table with relation ship and entry in one table may affect in other

suppose i have table called employee table with (empID,Emp_Name,email) field and other table profilePic with (empId,ImagePath) field
suppose i insert first into employee table data is inserted now i try to insert in to profilePic table and suppose error come so how to roll back last transaction from employee table

i want to ask when we create the employee entity in DAL what is the rule we have followed in other language if we have a stored procedure that will return an inner join between two tables should we create a specific entity like employee entity but only contains the fields in the stored procedure even these are from two or more tables

Hello,
First of All Thanx for This nice Article.
I have download the code but I am getting error in EmployeeDbAccess.cs file.
In EmployeeDbAccess.cs file i am getting error on below line
if (table.Rows.Count > 0)
So can you please give answer that how should i resolve that error.

Hi Mr Rahul
i use this method in my project and it was usefull for me. thanks
but when i add my website in IIS and brows it , i find this error in my browser:
A network-related or instance-specific error occurred while establishing a connection to SQL Server

could you check whether you are able to connect to the database using the connection string specified in the web.config. I think the problem could easily be resolved by putting the attached db in an sqlserver instance and changing the connection string in web.config to point to that.

Twenty years from now you will be more disappointed by the things that you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore, Dream. Discover.

I think we have to create a separate layer i.e Module Layer. Add Employee.cs to Module Layer and add reference of Module Layer to Presentation Layer. Then we do not need to add reference of Data Access Layer to Presentation Layer.

This is nice article, could you please elaborate little bit on the deployment side of the N-Tier applications. My questions is how do we deploy this application on separate physical tier and make all the layers of the application communicate with each other?