What is n-Tier Architecture?
This is a very important topic to consider when developing an application. Many elements need to be considered when deciding on the architecture of the application, such as performance, scalability and future development issues. When you are deciding on which architecture to use, first decide on which of the three aforementioned elements you think is most valuable -- as some choices you make will impact on others. For example, some choices that boost performance will impact on the scalability or future development of your design, etc.
Firstly, what is n-Tier architecture? N-Tier architecture refers to the architecture of an application that has at least 3 "logical" layers -- or parts -- that are separate. Each layer interacts with only the layer directly below, and has specific function that it is responsible for.
Why use n-Tier architecture? Because each layer can be located on physically different servers with only minor code changes, hence they scale out and handle more server load. Also, what each layer does internally is completely hidden to other layers and this makes it possible to change or update one layer without recompiling or modifying other layers.
This is a very powerful feature of n-Tier architecture, as additional features or change to a layer can be done without redeploying the whole application. For example, by separating data access code from the business logic code, when the database servers change you only needs to change the data access code. Because business logic code stays the same, the business logic code does not need to be modified or recompiled.
[Note] tier and layer mean the same thing [End Note]
An n-Tier application usually has three tiers, and they are called the presentation tier, the business tier and the data tier. Let's have a look at what each tier is responsible for.
Presentation Layer
Presentation Layer is the layer responsible for displaying user interface and "driving" that interface using business tier classes and objects. In ASP.NET it includes ASPX pages, user controls, server controls and sometimes security related classes and objects.
Business Tier
Business Tier is the layer responsible for accessing the data tier to retrieve, modify and delete data to and from the data tier and send the results to the presentation tier. This layer is also responsible for processing the data retrieved and sent to the presentation layer.
In ASP.NET it includes using SqlClient or OleDb objects to retrieve, update and delete data from SQL Server or Access databases, and also passing the data retrieved to the presentation layer in a DataReader or DataSet object, or a custom collection object. It might also include the sending of just an integer, but the integer would have been calculated using the data in the data tier such as the number of records a table has.
BLL and DAL
Often this layer is divided into two sub layers: the Business Logic Layer (BLL), and the Data Access Layers (DAL). Business Logic Layers are above Data Access Layers, meaning BLL uses DAL classes and objects. DAL is responsible for accessing data and forwarding it to BLL.
In ASP.NET it might be using SqlClient or OleDb to retrieve the data and sending it to BLL in the form of a DataSet or DataReader. BLL is responsible for preparing or processing the data retrieved and sends it to the presentation layer. In ASP.NET it might be using the DataSet and DataReader objects to fill up a custom collection or process it to come up with a value, and then sending it to Presentation Layer. BLL sometimes works as just transparent layer. For example, if you want to pass a DataSet or DataReader object directly to the presentation layer.
Data Tier
Data tier is the database or the source of the data itself. Often in .NET it's an SQL Server or Access database, however it's not limited to just those. It could also be Oracle, mySQL or even XML. In this article we will focus on SQL Server, as it has been proven to be the fastest database within a .NET Application.
Logical Layers vs. Physical Layers (Distributed)
Logical Layers and Physical Layers are the ones that confuse people. Firstly, a logical layer means that layers are separate in terms of assembly or sets of classes, but are still hosted on the same server. Physical layer means that those assemblies or sets of classes are hosted on different servers with some additional code to handle the communication between the layers. E.g. remoting and web services.
Deciding to separate the layers physically or not is very important. It really depends on the load your application expects to get. I think it's worth mentioning some of the facts that might affect your decision.
Please DO note that separating the layers physically WILL slow your application down due to the delay in communicating between the servers throughout the network, so if you are using the physical layer approach, make sure the performance gain is worth the performance loss from this.
Hopefully you would have designed your application using the n-Tier approach. If this is the case, then note that you can separate the layers in the future.
Cost for deploying and maintaining physically separated applications is much greater. First of all, you will need more servers. You also need network hardware connecting them. At this point, deploying the application becomes more complex too! So decide if these things will be worth it or not.
Another fact that might affect your decision is how each of the tiers in the application are going to be used. You will probably want to host a tier on a separate server if more than 1 service is dependent on it, e.g. You might want to host business logic somewhere else if you have multiple presentation layers for different clients. You might also want a separate SQL server if you have other applications using the same data.
[Note] You should develop an application bottom up. This means build the data tier layer first. You should always design all three layers before building the actual application. [End Note]
Performance vs. Scalability vs. Future Development
If you want scalability then you might have to sacrifice performance, because the scalability comes from scaling out and scaling out means communicating through a slower medium such as a LAN. Extensibility is a good thing to have but what's the point if you won’t be updating the application in the future, but instead be rewriting the whole thing? Think about whether you need extensibility or not because it can affect performance due to having more round trips to the database and also due to the simple fact that the size of the application will be bigger.
Think about what you really need for the project you are doing not what other people are doing for their projects. Architecture is a topic that really doesn't have best practices so rather than going for architecture for all of your applications, think about different architecture for each of your applications.
Presentation Tier Issues
The presentation layer must be well planned before building it. If this layer is badly designed, it could impact on the applications performance and future development paths. I'll explain why.
Firstly, let's start with performance. Remember how I said that the presentation layer 'uses' BLL to do any operations that need interaction with the data tier? No matter how well you've designed your BLL to reduce the round trips or unnecessary trips to the data tier, if the presentation layer code calls that method one or more times unnecessarily, you are still doing a round trip to the data tier. This impacts on your applications overall performance.
Performance is also affected by the different types of controls you decide to use. For example, using a DataGrid instead of a DataList or Repeater will make a noticeable performance difference. So, when do you use a DataGrid and when do you use others? We will discuss this in a minute.
Secondly, future development is also impacted upon if the presentation layer is badly designed. How? If you have repetitive HTML code in all pages of your website, what happens if you want to change a color of a table or something? Do you go to each page and change it? What would you do if your boss said "No, I don't like that... Change it back!"? You really need to implement a template system into your web pages, so when you make one change to your site design, it's propagated to all pages.
Although not related to performance and future development, the presentation layer has another role in ASP.NET applications – security. You have 4 security options in ASP.NET, and we will have a look at each option in detail shortly. Before that though, let's get back to the DataGrid, DataList and Repeater issue.
Data Grid, Data List, Repeater
Knowing the differences between these controls is very important because they are very different controls made for different uses, but people tend to get them confused.
Performance wise, you must always use a Repeater wherever possible. It is the fastest control out of the three. Unfortunately, it is also very limited in what it can do. All a repeater can do is iterate through the data source and display its properties.
A data source can be a data object such as a DataReader or dataset, but it can also be your custom collection that implements the IEnumerable and/or the IEnumerator interface. This is very good for displaying read only items such as list of news headlines, a summary of recent articles, etc.
There are times when you want to be able to "select" a row. When the row is selected, you want different item templates to be displayed. This situation is when you use a data list. DataLists allow you to select a row and display data using different templates. This is very useful for items that might need some frequent modification such as a list of news headlines for administrators where you want administrators to be able to edit headlines, etc.
The DataGrid is an interesting control. I always use it when I have a dataset as my data source. Although it's really slow, it is very flexible. It's also capable of producing a professional looking list or grid automatically. It knows the database's schema. It knows the type of fields and displays them accordingly. But one of the best features it has is its ability to allow editing of the data without having us code any postback functions, etc.
Here we will talk generally about what n-Tier architecture is, and then we will have a look at different n-Tier architectures you can use to develop ASP.NET applications and issues that arise relating to performance, scalability and future development issues for each one.
Firstly, what is n-Tier architecture? N-Tier architecture refers to the architecture of an application that has at least 3 "logical" layers -- or parts -- that are separate. Each layer interacts with only the layer directly below, and has specific function that it is responsible for.
Why use n-Tier architecture? Because each layer can be located on physically different servers with only minor code changes, hence they scale out and handle more server load. Also, what each layer does internally is completely hidden to other layers and this makes it possible to change or update one layer without recompiling or modifying other layers.
This is a very powerful feature of n-Tier architecture, as additional features or change to a layer can be done without redeploying the whole application. For example, by separating data access code from the business logic code, when the database servers change you only needs to change the data access code. Because business logic code stays the same, the business logic code does not need to be modified or recompiled.
[Note] tier and layer mean the same thing [End Note]
An n-Tier application usually has three tiers, and they are called the presentation tier, the business tier and the data tier. Let's have a look at what each tier is responsible for.
Presentation Layer
Presentation Layer is the layer responsible for displaying user interface and "driving" that interface using business tier classes and objects. In ASP.NET it includes ASPX pages, user controls, server controls and sometimes security related classes and objects.
Business Tier
Business Tier is the layer responsible for accessing the data tier to retrieve, modify and delete data to and from the data tier and send the results to the presentation tier. This layer is also responsible for processing the data retrieved and sent to the presentation layer.
In ASP.NET it includes using SqlClient or OleDb objects to retrieve, update and delete data from SQL Server or Access databases, and also passing the data retrieved to the presentation layer in a DataReader or DataSet object, or a custom collection object. It might also include the sending of just an integer, but the integer would have been calculated using the data in the data tier such as the number of records a table has.
BLL and DAL
Often this layer is divided into two sub layers: the Business Logic Layer (BLL), and the Data Access Layers (DAL). Business Logic Layers are above Data Access Layers, meaning BLL uses DAL classes and objects. DAL is responsible for accessing data and forwarding it to BLL.
In ASP.NET it might be using SqlClient or OleDb to retrieve the data and sending it to BLL in the form of a DataSet or DataReader. BLL is responsible for preparing or processing the data retrieved and sends it to the presentation layer. In ASP.NET it might be using the DataSet and DataReader objects to fill up a custom collection or process it to come up with a value, and then sending it to Presentation Layer. BLL sometimes works as just transparent layer. For example, if you want to pass a DataSet or DataReader object directly to the presentation layer.
Data Tier
Data tier is the database or the source of the data itself. Often in .NET it's an SQL Server or Access database, however it's not limited to just those. It could also be Oracle, mySQL or even XML. In this article we will focus on SQL Server, as it has been proven to be the fastest database within a .NET Application.
Logical Layers vs. Physical Layers (Distributed)
Logical Layers and Physical Layers are the ones that confuse people. Firstly, a logical layer means that layers are separate in terms of assembly or sets of classes, but are still hosted on the same server. Physical layer means that those assemblies or sets of classes are hosted on different servers with some additional code to handle the communication between the layers. E.g. remoting and web services.
Deciding to separate the layers physically or not is very important. It really depends on the load your application expects to get. I think it's worth mentioning some of the facts that might affect your decision.
Please DO note that separating the layers physically WILL slow your application down due to the delay in communicating between the servers throughout the network, so if you are using the physical layer approach, make sure the performance gain is worth the performance loss from this.
Hopefully you would have designed your application using the n-Tier approach. If this is the case, then note that you can separate the layers in the future.
Cost for deploying and maintaining physically separated applications is much greater. First of all, you will need more servers. You also need network hardware connecting them. At this point, deploying the application becomes more complex too! So decide if these things will be worth it or not.
Another fact that might affect your decision is how each of the tiers in the application are going to be used. You will probably want to host a tier on a separate server if more than 1 service is dependent on it, e.g. You might want to host business logic somewhere else if you have multiple presentation layers for different clients. You might also want a separate SQL server if you have other applications using the same data.
Performance, Scalability and Future Development
As I said earlier, each choice you make in the architecture will affect one of the following:- Performance
- Scalability
- or Future Development.
[Note] You should develop an application bottom up. This means build the data tier layer first. You should always design all three layers before building the actual application. [End Note]
Performance vs. Scalability vs. Future Development
When deciding on your architecture, decide what your priority is going to be. If your application is time critical, then you might have to sacrifice its scalability and extendibility just because you need more procedural like class design, which will offer that.
If you want scalability then you might have to sacrifice performance, because the scalability comes from scaling out and scaling out means communicating through a slower medium such as a LAN. Extensibility is a good thing to have but what's the point if you won’t be updating the application in the future, but instead be rewriting the whole thing? Think about whether you need extensibility or not because it can affect performance due to having more round trips to the database and also due to the simple fact that the size of the application will be bigger.
Think about what you really need for the project you are doing not what other people are doing for their projects. Architecture is a topic that really doesn't have best practices so rather than going for architecture for all of your applications, think about different architecture for each of your applications.
Presentation Tier Issues
The presentation layer must be well planned before building it. If this layer is badly designed, it could impact on the applications performance and future development paths. I'll explain why.
Firstly, let's start with performance. Remember how I said that the presentation layer 'uses' BLL to do any operations that need interaction with the data tier? No matter how well you've designed your BLL to reduce the round trips or unnecessary trips to the data tier, if the presentation layer code calls that method one or more times unnecessarily, you are still doing a round trip to the data tier. This impacts on your applications overall performance.
Performance is also affected by the different types of controls you decide to use. For example, using a DataGrid instead of a DataList or Repeater will make a noticeable performance difference. So, when do you use a DataGrid and when do you use others? We will discuss this in a minute.
Secondly, future development is also impacted upon if the presentation layer is badly designed. How? If you have repetitive HTML code in all pages of your website, what happens if you want to change a color of a table or something? Do you go to each page and change it? What would you do if your boss said "No, I don't like that... Change it back!"? You really need to implement a template system into your web pages, so when you make one change to your site design, it's propagated to all pages.
Although not related to performance and future development, the presentation layer has another role in ASP.NET applications – security. You have 4 security options in ASP.NET, and we will have a look at each option in detail shortly. Before that though, let's get back to the DataGrid, DataList and Repeater issue.
Data Grid, Data List, Repeater
Knowing the differences between these controls is very important because they are very different controls made for different uses, but people tend to get them confused.
Performance wise, you must always use a Repeater wherever possible. It is the fastest control out of the three. Unfortunately, it is also very limited in what it can do. All a repeater can do is iterate through the data source and display its properties.
A data source can be a data object such as a DataReader or dataset, but it can also be your custom collection that implements the IEnumerable and/or the IEnumerator interface. This is very good for displaying read only items such as list of news headlines, a summary of recent articles, etc.
There are times when you want to be able to "select" a row. When the row is selected, you want different item templates to be displayed. This situation is when you use a data list. DataLists allow you to select a row and display data using different templates. This is very useful for items that might need some frequent modification such as a list of news headlines for administrators where you want administrators to be able to edit headlines, etc.
The DataGrid is an interesting control. I always use it when I have a dataset as my data source. Although it's really slow, it is very flexible. It's also capable of producing a professional looking list or grid automatically. It knows the database's schema. It knows the type of fields and displays them accordingly. But one of the best features it has is its ability to allow editing of the data without having us code any postback functions, etc.
