3 Tier Architecture vs 2 Tier Architecture

Question

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.

Answer 1

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.

Answer 2

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.