The 3 Tier Architecture

Any piece of software can be subdivided into the following areas:-

• Presentation logic = User Interface, displaying data to the user, accepting input from the user.
• Business logic = Business Rules, handles data validation and task-specific behaviour.
• Data Access logic = Database Communication, constructing SQL queries and executing them via the relevant API.

If you put the code which deals with presentation logic (the generation of HTML documents), business logic (the processing of rules) and data access logic (the generation and execution of DML statements) into a single component then what you have is a single tier structure, as shown in snap.


















If you split off all the code that handles the communication with the physical database to a separate component then you have a 2 tier architecture, as shown in snap.

















If you go one step further and split the presentation logic from the business logic you have a 3 Tier Architecture, as shown in snap. Note that there is no direct communication between the presentation and data access layers - everything must go through the business layer in the middle.

















When this architecture is implemented the benefits will become apparent as more code can be shared instead of being duplicated. Several components in the presentation layer can share the same component in the business layer, and all components in the business layer share the same component in the data access layer.

The big advantage of a 3-tier system is that it is possible to change the contents of any one of the tiers/layers without having to make corresponding changes in any of the others. For example:

• A change from one DBMS to another would only require a change to the component in the data access layer.
• A change in the Use Interface, for example from desktop to the web, would only require changes to the components in the presentation layer.