Multi-tier Enterprise Application Architecture

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.

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.

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 overthe database tables.

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.

Share

About the Author

I am currently a DOT NET Software Consultant. Having said that, I am well versed in both front and backend. I got a very good amount of hands on experience in ASP.NET , T-SQL and a good amount of Database Administration, AJAX, JavaScript, SSIS and SSRS.

I am well versed in Enterprise Level Applications Architecture and Development.

I am even currently working as a Freelancer and build Content Management Systems in PHP and MYSQL.

If this article is nothing new for you, could you please point me where I could read about the idea behind IXORBusinessLogic interface? I am still not sure about is this really useful and would like to learn more about this.

Nice article. Especially, I liked the idea of having common base interface for all domain processes. I would like to look at this idea closer, but I can't find where I can download article's source code. Am I missing something or you didn't share it? Could you share it, please?

The article is clear and very well written. I have a comment concerning the business layer having the user interface layer as a reference. In general, lower level layers should not have any knowledge about higher level layers. You mention that in regards to the data layer having no knowledge about the business layer (or the user interface layer). The same should apply to the business layer. It should have no knwoledge about the user interface layer.
In any case you still get my five.