I just came across the following sentence:
As the industry has moved from a three tier model to n-tier models, the object relational impedance mismatch has become more prevalent.
But I can't find a concise explanation of the difference between three tier and n-tier. I know what three tier is, and I assume n-tier just adds one or more tiers. I'm just not sure what these additional tiers would be. If anyone has a short explanation or simply a good link, that would be much appreciated.
They are the same basic architectural pattern, but 3-tier always has 3 tiers, while n-tier has a variable number of tiers.
What Does N-Tier Architecture Mean? N-tier architecture is a client-server architecture concept in software engineering where the presentation, processing and data management functions are both logically and physically separated.
Three-tier architecture, which separates applications into three logical and physical computing tiers, is the predominant software architecture for traditional client-server applications.
Three-tier architecture is a well-established software application architecture that organizes applications into three logical and physical computing tiers: the presentation tier, or user interface; the application tier, where data is processed; and the data tier, where the data associated with the application is ...
In development we understand a tier as a "level of responsibility" abstraction.
Such level of responsibility groups concepts together to provide a coherent semantic view of reality, or at least something similar to reality.
In such sense, the so called, 3-tier model or n-tier models are just different implementations of that concepts.
A good example of a tier follows the jerarquical model where responsibilities are carefully addressed to the appropriate people. For example, a common business has Commercial, Marketing, Systems, Development and Test department (for example), which represent tiers of business. That way, responsibilities are clear, Development provides the product, Testing test it, Marketing promote it and Commercial sell it, all that while systems keep the infrastructure running (is just an example).
This metaphor was first approached with the 3-tier model, where three tiers are identified. Usually this tiers are Database Abstraction Layer, which is in charge of communication and abstraction over the database, Business Rules Layer, which holds the rules that describe the business process and User Interface Layer which abstracts the interaction of the user with the system.
That way, we have roles for the responsibilities of each layer, so that if the user needs to interact with the system he will communicate with one layer, not mess up across the hole system.
N-tier represent an evolution of the former concept by using more tiers to address specific needs. Usually user interface layer and database abstraction layer are left untouched, as their roles are pretty clear while business rules layer is further refined.
For that, we always take into account the characteristics of the problem as well as the features we want to provide now and in the future. For example, if an application will need to work with smart clients or its foreseen to work with smart clients then business layer is usually divided into a proxy layer and a back-end layer, the first routing the calls where they should go.
In the end, what's important is the concept of abstracting responsibilities among different layers, and centralizing all related operations from a semantic view in the same place.
Note that, in addition, n-tier architecture allows for distribution of those "responsibilities" among developers. That way, a given team can have responsibility over the Database Abstraction Layer while other team works on the Proxy Layer and another one works on the Graphics Abstraction Layer. When a member of a team needs to access the database he look up the DAL documentation and use one of the facilities provided or ask the DAL team to provide with the functionality he needs, so that he does not address directly the database but through the people that better known the design and intricacies of the database itself.
If we looked at tiers like being layers of a cake; each layer would have it's own ingredients and do it's own things. The tiers of each application interact with only the tier above it, or below it.
3-tier means the cake has 3 layers. Usually it's data at the bottom, then an application logic tier (PHP/ruby/etc), and then a presentation tier at the top (html)
Having an n-tier architecture means you design something multiple layers layer to it. The number of layers you have will depend on how you decide to make it.
It seems to make a lot more sense with larger, or web applications.
I usually end up with a 5 tier application. Each tier can only interact with the one above it or below it. This can provide fantastic extensibility and standardization across your application.
Client Tier
Web Browser
Presentation Tier
Render the HTML - Coldfusion/Flash/Ruby/PHP,etc.
Business Logic Tier
Run the processes and calculations as needed - Coldfusion/Flash/Ruby/PHP,etc.
Data Integration Tier
(Queries from my Development Language, Stored Procedures, etc.)
Data Tier
(Database - MySQL, etc)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With