Introduction
Multitier architecture, often referred to as ‘N’-tier architecture, is a software system that is segregated into separate sections referred to as tiers, or layers. By default, the ‘N’ value is presumed to be three.
The first and the foremost question for a person after reading the above lines, "Why do I need these layers, what purpose do they solve?".
Software applications are constructed with this methodology for many a reasons. Foremost is the ability to provide the optimal amount of “scalability” to the system and allow any of the tiers to be upgraded, replaced, or interchanged independently.
At some point in a software system, there is the inevitable “Change”. This change can come in the form of a functionality change, a functionality enhancement, a completely new module, or even a hardware infrastructure enhancement and so on. In any case, changes can occur during the initial development or after the first version is complete. Thus it becomes mandatory to have the architecture of the system designed from the beginning as “multitiered”. This will help us to minimize the impact on the system when implementing any change to any layer.
As a result of having the source code organized into multiple tiers, debugging and maintaining your application as a whole will be easier. The organization will allow for you as a developer (or any other developers you might be working with) to easily locate specific sections where an exception is occurring or where a change needs to be implemented.
If the system does not implement a well-structured architecture, your application will be prone to defects and bugs; this will also make any type of upgrades or enhancements difficult and time-consuming to execute. The system will not be very scalable, which will result in a poor application.
A typical multi-tiered application consists of:
- Presentation Layer (this is simply our website application)
- Business Logic Layer (the Brain of our application)
- Data Access Layer (the Data Processing section of our application)
Now comes a quick question. “Do all these layers exist on only one machine?” Yes and No! Confused? Don’t be. This is how it works!
In a multitier architecture, all the layers are present like the above three. It all depends upon the fact if the layers are all on one machine itself or distributed over several machines across the network.
Let us say, we need to get the web-server running, store our data in the database and have the web application also running on the same server (low budget project :)). Then this would also be called as a 3-tier application.
Detailed Description
Consider the following image below as a reference for the upcoming description:
Overall Solution Structure
Presentation Layer
This is the presentation logic layer. This is what the users will view. This includes simple control and user input validation. This application is also known as a thin client. It is similar to our web application. It has a reference of our business layer. This layer has no knowledge about the system working, database or any information.
Example
The following page is in the code behind file of an aspx page. There is a reference to the Business Layer only in the following sentence.
using XOR.Development.Ecommerce.XORBusinessObjects;
using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using XOR.Development.Ecommerce.XORBusinessObjects;
namespace XOR.Development.Ecommerce.WebApp
{
public partial class Search : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
}
protected void btnUserRegister_Click(object sender, EventArgs e)
{
}
}
}
Business Logic Layer
This is the ‘brain’ of our entire application. It provides the business processes logic and the data access. The business logic layer of the architecture will act as a bridge from the presentation to the data access so that the information can be processed in some cases and, in other cases, can simply be the conduit to ensure the smooth flow of information. This layer will have the most information about the activity and the processing that needs to take place. This layer will have heavy implementation of the business objects.
This layer does not know any information to access data. In fact, it has no knowledge how to retrieve information. It just gives the requirement to the Data Access Layer. This layer sets forth the business rules from the earlier gathered requirements. Look at the references in the below picture for a clear understanding.
Sample Business Layer Project in a Solution
Example
The example below is the class file which accepts data from the presentation layer. This layer has references of Common Objects, Data Access Layer, Business Interface Libraries.
The application example here uses the ‘ProcessSelectProducts’ class file in the data access layer. It sends information to the file (ProcessSelectProducts) which gets the data from the database.
using System;
using System.Collections.Generic;
using System.Text;
using System.Data;
using XOR.Development.Ecommerce.XORBusinessInterface;
using XOR.Development.Ecommerce.XORCommonObjects;
using Microsoft.ApplicationBlocks.Data;
using Microsoft.ApplicationBlocks.Data.Select;
namespace XOR.Development.Ecommerce.XORBusinessObjects
{
public class ProcessGetProducts : IXORBusinessLogic
{
public ProcessGetProducts()
{
}
private string _searchcriteria;
public string SearchCriteria
{
get { return _searchcriteria; }
set { _searchcriteria = value; }
}
private DataSet _resultset;
public DataSet ResultSet
{
get { return _resultset; }
set { _resultset = value; }
}
#region IXORBusinessLogic Members
public void Invoke()
{
ProcessSelectProducts oProcessSelectProducts = new ProcessSelectProducts();
ResultSet = oProcessSelectProducts.Get(SearchCriteria);
}
#endregion
}
}
Data Access Layer
This is the only layer in our application which knows how to interact with the database servers and retrieve the required information. It has no knowledge as to who is asking or whom is it giving the information to. All it knows is that it needs to give information back to the request object.
Data retrieval process will most likely be in the form of selecting, querying, inserting, updating, or deleting information to and from the database. Other processing includes utilizing Extensible Markup Language (XML) data but this will ultimately vary based upon your specific system and its business requirements.
Example
Consider the example below.
This class file in the data access layer is used to perform the ‘Select’ operation over
the database tables.
using System;
using System.Collections.Generic;
using System.Text;
using System.Data;
using System.Data.SqlClient;
using XOR.Development.Ecommerce.XORCommonObjects;
namespace Microsoft.ApplicationBlocks.Data.Select
{
public class ProcessSelectProducts : XORDataAccessBase
{
public ProcessSelectProducts()
{
StoredProcedureName = XORStoredProcedures.Name.USP_SearchAllProducts.ToString();
}
public DataSet Get(string SearchCriteria)
{
DataSet ds;
ProductSelectSearchDataParameters oProductSelectSearchDataParameters =
new ProductSelectSearchDataParameters(SearchCriteria);
XORDataBaseHelper dbhelper = new XORDataBaseHelper( StoredProcedureName );
ds = dbhelper.Run
(ConnectionString,oProductSelectSearchDataParameters.Parameters);
return ds;
}
}
public class ProductSelectSearchDataParameters
{
private string _searchcriteria;
private SqlParameter[] _parameters;
public string SearchCriteria
{
get { return _searchcriteria; }
set { _searchcriteria = value; }
}
public SqlParameter[] Parameters
{
get { return _parameters; }
set { _parameters = value; }
}
public ProductSelectSearchDataParameters(string searchcriteria)
{
SearchCriteria = searchcriteria;
Build();
}
private void Build()
{
SqlParameter[] parameters =
{ new SqlParameter("@UserSearchText", SearchCriteria) };
Parameters = parameters;
}
}
}
Business/Common Objects
This is the layer which contains all the entities like credit card entity, address entity, end user entity and so on. Business/Common objects will also provide a direct mapping from the database tables you created earlier to the classes within your code. This does not necessarily imply that every common/business object will be a table within the database. Many will, but sometimes we will need a container of information that needs to be passed throughout the application. This will come in the form of a common object.
Sample Business/Common Objects
Example
Consider the following example. This is a class file which describes the Order details.
It consists of all the requirements which consist of fields in the order processing.
using System;
using System.Collections.Generic;
using System.Text;
namespace XOR.Development.Ecommerce.XORCommonObjects
{
public class OrderDetailsEntity
{
public OrderDetailsEntity()
{
}
private int _orderDetailsIdField;
private int _orderIdField;
private int _productIdField;
private string _productField;
private int _quantityField;
public int OrderDetailsId
{
get
{
return _orderDetailsIdField;
}
set
{
_orderDetailsIdField = value;
}
}
public int OrderId
{
get
{
return _orderIdField;
}
set
{
_orderIdField = value;
}
}
public int ProductId
{
get
{
return _productIdField;
}
set
{
_productIdField = value;
}
}
public string ProductField
{
get
{
return _productField;
}
set
{
_productField = value;
}
}
public int Quantity
{
get
{
return _quantityField;
}
set
{
_quantityField = value;
}
}
}
}
Conclusion
This concludes the multi-tier application architecture. I hope this article gives you insight into the advantages of splitting the application into multi layers. Good luck!!
History
- 19th January, 2009: Initial post
