Multi Tier Architecture

Also commonly referred to as an n-Tier architecture.

This means splitting a system into more than just a client layer and a database layer. Instead, we have the clients, and they only deal with presenting data to the user and sending changes back to the server. The server in this case refers to a custom written thing (commonly down using MTS, ComPlus, CORBA or EnterpriseJavaBeans, but could be anything). The server then takes care of the business logic, and gets and returns the raw data to one or more database servers.

That is just a basic idea of the setup. It used to be called a 3 tier architecture, but then people started splitting it up into more than just 3 tiers, so they switch to calling in n-Tier.

The advantages are better maintainability (business logic can be changed without updating every client machine), and if used in conjunction with a Transaction processing or thread/connection pooling system, n-Tier stuff can provide better performance than 2 tier.

I would question this. The more layers of abstraction you add, the slower things get. Which do you think is faster, a kernel-mode webserver or one that is layered on the OS? (i.e. compare khttpd and Apache). You can thread a 2-tier app too.

I think the advantage is in the possibility of true physical separation. It is conceptually useful to take a logical view of tiers as layers on some abstract machine, it is also useful to regard it as a set of independent peer machines connected by a network. Considerations such as bandwidth, storage and CPU requirements then constrain the assigned location of the logical units. -- RichardHenderson

The performance improvement comes from moving the BusinessLogic from the client to the server.

We have control over hardware at the server end, we often don't have control over the client end.
Lighter clients can sometimes be more responsive to user actions, providing at least the illusion of better performance (which in itself is valuable)
BusinessLogic often entails multiple queries to the DB to execute a single logical operation. By moving this logic to the server these queries are executed over network infrastructure you control.
Server-side business object often has a more linear flow of control over the more asynchronous event-driven code structure common in client applications. This can
- reduce development time
- reduce code complexity (with associated reliability improvements)
- provide a more granular target for profiling and optimization.
Hides database implementation details from the client. I believe this would be considered an application of the FacadePattern. Theoretically this allows you to move from a localstorage-flatfile DB to a full HSM RDBMS or OODB without changing a single line of client code.

Effectively, I see MultiTierArchitecture as being a direct result of ReFactoring the client end and subsequently migrating the resulting Model code to the server end using an appropriate distributed system/object technology. (Personally I prefer using CORBA, although my current project is using EJB's.) -- Andrae Muys

If the bandwidth from the server room to the desktop PCs is limited, doing the processing within the computer room can be faster.

Database backed web sites are generally 3 tier (web browser, webserver, and database server).

A less systems oriented view would possibly consider the cgi/asp/servlet stuff as the top tier, business logic as the second tier, and the database schema as the third tier. If you have objects which are about writing web pages, and interpreting HTTP, that's not part of the business process, it's part of the presentation. Hmmm. Isn't this already documented here as a pattern?

Then you probably have a FourLayerArchitecture where the application and domain model layers share the second tier (the web server) or?

See: HexagonalArchitecture, ThreeTierArchitecture

CategoryArchitecture