3 Tier Architecture vs 2 Tier Architecture

问题:

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.

回答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.

回答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.

回答3:

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)

回答4:

Some cases that may drive you move from 2-tier to 3-tier: 1- Your system has different type of clients (Desktop, Web, Mobile, etc.) 2- Your system has heterogeneous type of data sources (eg. non-DB resources)
3- Your system needs specific client/server communication protocol 4- You want to hide and secure data tier from client 5- You need scalability by cluster of servers and load balancing 6- You need server to server integration that is transparent for client 7- You want to use shared resources for number of clients (such as DB Connection) 8- You want to simplify system maintenance by decoupling the client from db server or group of servers 9- You want to put the business logic into a separate tier on specific platform 10- You want to reduce traffic between client and DB

回答5:

First, great question. As others have noted, both have merits. "Seperation of concern" is the primary benefit of 3-tier and that pays dividends in several ways:

1. Security: By separating your business logic from presentation, you can apply more strict policies to the various layers e.g. presentation forms with no data or logic can be in your presentation zone so anonymous users can get to your 'public' content.
2. Maintainability/Manageability - much has already been said about this
3. Reuse/Disaster Recovery: For instace, if a pharamcy management app may want to expose a UI as well as services that third parties can use to place prescription orders. By separating business logic into a separate layer, you can maintain the services/logic independently of the UI

There are several others but these hopefully give an idea of potential benefits

回答6:

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.