Difference between three tier vs. n-tier
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.
Answer
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.