Multi-Tier Architecture: The Three Tier Model
Multi-Tier Architecture The Three Tier Model Business applications today all access data as part of their core functionality. As relational database servers gained in popularity 20 years ago, the industry moved from a one tier (mainframe) model to a client server model where we had a client performing the presentation logic and most of the business logic and the server with the data storage and some business logic in the form of stored queries. By the early 1990s this model broke down due to high maintenance costs and a lack of a separation of concerns and we moved to a three-tier architecture as shown in the figure below. {draw:frame} Three-tier architecture enforces a logical (and sometimes physical) separation of three major concerns: Presentation: the user interface components. The goal of separating the logic is twofold: First there is a performance gain by having the database server focus only on database storage and retrieval. Specific hardware and topologies (such as RAID) are used for database storage and access that are different from an “application server” or middle tier of business objects and logic. In addition with powerful client machines it made sense to push UI processing down to the client. Second was the separation of concerns principle. By separating out the logic of a system, you can easier maintain the overall system, reuse code, and keep associated logic and code in one location. *The n-*Tier Model {draw:frame} The Problem with the nTier Architecture The n-tier architecture has been very successful. Most sophisticated applications today use some form of the n-tier model. Years ago to support this model, enterprises would have as many as five different job titles around the data centric business application. The job titles were: Data Modeler Database Administrator SQL Programmer Object Modeler Application Developer The data modeler would design the physical tables