Learn IT

Free learning anything to everything in Information Technology.

3-Tier Architecture Implementation for Web Applications

A 3-Tier Architecture implementation in a web based application scenario is defined as three layers of hardware, as in “web server + application server + database server”. Although it is possible to physically deploy a software application over three layers of hardware, we must divide the application code into three layers of software to begin with so that we actually have something that can occupy each piece of hardware. The former is known as physical 3-tier while the latter is known as logical 3-tier. It should be possible for a logical 3-tier application to be deployed on a single physical device as well as several devices. It is a deployment strategy to decide the installation of the system; we will only describe the logical 3-tier here.
The three logical layers are defined as:
  • Presentation logic - accepting user input and generating user output - the User Interface (UI).
  • Business logic - the processing of business rules and task-specific behaviors.
  • Data Access logic - communicating with the physical database using the APIs provided by that database engine.

These areas are also referred to as layers or tiers.
This pattern can be represented in the following diagram:

The presentation layer never talks to the data access layer directly - it talks only to the business layer. The business layer receives requests from the presentation layer, which may be:

  • Requests to read data, in which case the business layer may instruct the data access layer to obtain the data from the database. Note that a single request may not be limited to a single database table.
  • Requests to write data, in which case the business layer will apply the relevant validation rules before instructing the data access layer to write it to the database. Note that a single request may not be limited to a single database table.

Among the advantages of separating the application logic in this manner are:

  1. Maximises code reuse and minimises code duplication. For example, each business entity has a single component in the business layer, and all presentation layer components which want to access this business entity go through the same business layer component.
  2. It is possible to modify the application by making changes to just one tier, leaving the other two unaffected by the change. For example: It should be possible to change the presentation layer, such as from client/server to the web, without affecting the business or data access layers. It should be possible to change the business rules for an entity without affecting the presentation or data access layers. It should be possible to change the data access layer, such as switching from one database engine to another, without affecting the presentation and business layers.
  3. As each tier is now independent of the other it becomes possible to use different sets of developers, with different skill sets, for each tier. This may reduce the need for multi-skilled developers.

0 comments: