What are the examples where we really need 3 Tier Architecture ? Can Most of the Application which are using 3 Tier Architecture be done using 2 Tier Architecture ?
Note: I am trying to see value of 3 Tier Architecture, I feel most of the application that there are 3 tier right now can be done in 2 tier and so I am looking for examples where we absolutely need 3 tier and there is no exception to that need.
I'm guessing that you mean layered (logical units of separation) rather than tiered (physical units of separation/deployment). An example of a tiered system would be a web server (1 tier) delivering web pages (another tier) which draws on data from a database the 3rd tier).
The usual aim of a layered architecture is to separate out responsibilities. This has two key benefits (amongst others).
First of all your design will be clearer as responsibilities won't be muddied and thus the code will be easier to read, understand and maintain.
Secondly the chances are you'll be reducing duplication - for example in a web app if your pages are also handling business logic (or horror of horrors data access) as well as displaying the pages then you can be fairly sure that multiple pages will be trying to do the same or similar things.
You don't need to architect (e.g. into layers, although there are other ways) any piece of software but for anything apart from trivial things the result will be an unmaintainable mess if you don't.
Well if you have a website... You probably have some Javascript code, so that is once tier, you have your business logic in the server and you have the database to store things. That is three tiers in my opinion. Of course you could use stored procs in the database and skip the business logic tier so it is possible to build a website that with two tiers if you want to but if you don't want to use stored procs you will have three tiers.
Props to FinnNk, but let me give you an example of what happens when you don't separate your tiers. I've worked, for years now, on a project that was badly separated at birth. All three tiers -- more, if you believe what tuinstoel said -- lumped into individual JSP pages. I'm sure it seemed like a smart thing at the time (faster to code when you're just starting) but this monstrosity has grown and grown, and no one took the time to refactor.
We now have 2000+ JSP pages, with duplicate code scattered throughout. Making a schema change requires careful backtracking to figure out what pages might be effected, and individual testing of each of those pages. No one in management thinks it's important enough to spend the time to fix this -- short term gains, long term loss.
Do. Not. Go. This. Route.
Separating tiers leads to better, faster, more testable, more modular code. You'll thank yourself for it, and (more importantly) the people who come after you will thank you for it.
Some databases expose a rest interface to the outside world, for instance NoSQL databases CouchDB and RavenDB. That means that the Javascript running in your browser can call the database without a middle tier.
See for example: http://www.infoq.com/news/2010/06/couchdb
" Well behaved HTTP/REST interface and API Clean and simple two tier applications (html+javascript in the browser + couch+javascript as server)"
Oracle has a web server inside, you can use stored procs that also expose a rest interface to the outside world. So the JavaScript in your browser can also call the Oracle database without a middle tier.
Do you always need a middle tier when all you want is to get some data from the database? I question that need.
(TTT formerly known as Tuinstoel)