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.
On
Without seeing the sentence in context, I assume it is referring to the explosion in services and middleware.
On
Where is that quote from? What industry are they referring to? I would have to imagine that this has something to do with SOA because that is the only thing that makes sense for this kind of statement.
Most people that I have heard who make this kind of statement believe that in a service-oriented domain each service is somehow its own tier. I disagree as most of the time these disparate services can be logically grouped into the common three tiers anyhow (presentation, logic, and data). But again, its all pretty subjective.
On
Hey I can't even get a definition of 3 tier. Sometimes they discount javascript on the client and sometimes javascript on the client and the client web browser are considered another tier. So an ASP page that talks to a database can be 3 tier if you assume database = tier 3, web server = tier 2, client web browser = tier 1. And other times web server = tier 1, middleware = tier 2, database = tier 3. It really depends who is writing the definition/book.
In general n-tier seems to refer splitting the middleware layer up more. But aside from that I don't see consistent definitions.
On
n-tier implies n is any number - when n=3 then it is the same as n-tier.
The usual definition of 3-tier is presentation, logic & data (in any order), and yes, SOA can confuse the neophyte because sometimes it sits in the data tier, sometimes the logic tier and sometimes both logic & data tiers.
The whole subject is...subjective. If you need some tiers then call it n-tier - if you know that n=7 then call it 7-tier, or n-tier.
On
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.
On
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)
On
This Wiki-book chapter on application architecture is a straightforward guide to layers, tiers, and deciding what you need to use.
The quote appears to be from this codeproject page. It also seems to do a pretty good job of explaining n-tier to include things like web services, javascript, workflows, etc. All things that 3-tier models don't necessarily include.