3 Tier Architecture

3 Tier Architecture

Simple diagram which shows a 1-Tier application where the Presentation logic, Business logic and Data Access logic are all contained within a single component:

Figure 2 - 1 Tier architecture

Although this diagram apparently makes it easy to identify the different areas of responsibility, in real life the actual program code may be so inter-mingled, inter-twined and spaghetti-like that it would be extremely difficult to locate the boundaries between each area of responsibility. A blurry mess like this is shown in figure 3:

Figure 3 - Typical program with blurry boundaries

The 2-Tier Architecture

My first exposure to a software architecture which had more than one layer was with a compiled language where all database access was handled by a completely separate component which was provided by the vendor, as shown in figure 4:

Figure 4 - 2 Tier architecture

This was a deliberate feature of the language as it enabled an application to be readily switched from one DBMS engine to another simply by loading a different data access component. No other part of the application was allowed to communicate with the database, so this component could be switched without affecting any other part of the application. This made it possible to develop an application using one DBMS, then deploy it with another.

Note that the presentation logic and the business logic are still intermingled.

The 3-Tier Architecture

This is where the code for each area of responsibility can be cleanly split away from the others, as shown in figure 5:

Figure 5 - 3 Tier Architecture

Note here that the presentation layer has no direct communication with the data access layer - it can only talk to the business layer.

Note also that you should not infer from this diagram that the entire application can be built with a single component in each of these three layers. There should several choices as follows:

• There should be a separate component in the Presentation layer for each user transaction.
• There should be a separate component in the Business layer for each business entity (database table).
• There should be a separate component in the Data Access layer for each supported DBMS.

With this structure it is easy to replace the component in one layer with another component without having to make any changes to any component in the other layers.

• You can change the UI component so that you can switch between a variety of different output formats, such as HTML, PDF or CSV.
• You can change the data access component so that you can switch between a variety of database engines, such as MySQL, Oracle or SQL Server.

This structure also provides more reusability as a single component in the Business layer can be shared by several components in the Presentation layer. This means that business logic can be defined in one place yet shared by multiple components.

The Rules of the 3 Tier Architecture

It is simply not good enough to split the code for an application into 3 parts and call it "3 Tier" if the code within each tier does not behave in a certain way. There are rules to be followed, but these rules are pretty straightforward.

• The code for each layer must be contained with separate files which can be maintained separately.
• Each layer may only contain code which belongs in that layer. Thus business logic can only reside in the Business layer, presentation logic in the Presentation layer, and data access logic in the Data Access layer.
• The Presentation layer can only receive requests from, and return responses to, an outside agent. This is usually a person, but may be another piece of software.
• The Presentation layer can only send requests to, and receive responses from, the Business layer. It cannot have direct access to either the database or the Data Access layer.
• The Business layer can only receive requests from, and return response to, the Presentation layer.
• The Business layer can only send requests to, and receive responses from, the Data Access layer. It cannot access the database directly.
• The Data Access layer can only receive requests from, and return responses to, the Business layer. It cannot issue requests to anything other than the DBMS which it supports.
• Each layer should be totally unaware of the inner workings of the other layers. The Business layer, for example, must be database-agnostic and not know or care about the inner workings of the Data Access object. It must also be presentation-agnostic and not know or care how its data will be handled. It should not process its data differently based on what the receiving component will do with that data. The presentation layer may take the data and construct an HTML document, a PDF document, a CSV file, or process it in some other way, but that should be totally irrelevant to the Business layer.