3-Tier, 3-Layer, MVC

3-Layered Architecture
This approach implies a division of responsibilities in logical components. They are:

• Presentation, where input forms and results are rendered
• Business, or also Domain Logic, where core application logic lives. Here it's all about business nouns: Customers, Invoices, Purchases, etc. No explicit references to rendering mechanisms or persistence ones are made here
• Data Access, where all those concerns related with persistence mechanisms (database connections, tables, records, etc) take place

Although a physical distribution of these or other application components can arise, this is not mandatory. Actually the benefits this architecture style brings are maintenance and reusability
Maintenance, because every layer comprises a set of few, cohesive APIs (the Presentation layer, APIs like WinForms, or ASP.NET, maybe Atlas; the Data Access layer, possibly ADO.NET, System.Xml; the Business layer probably can be almost agnostic of platform APIs, except the basic ones like Collections, etc)
Reusability is possible as we can add a new presentation layer for mobile devices, change the persistence mechanism by another database, possibly some static data in XML; but changes in one layer shouldn't impact on the others
For a deeper discussion on 3-Layered Architecture, I suggest the chapter ad hoc at the book Enterprise Solution Patterns (MS Patterns and Practices): http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnpatterns/html/ArcThreeLayeredSvcsApp.asp

3-Tier Architecture
In this approach, we privilege a physical division of activities. Let's see:

• Client (aka Front-end, Channels), consistent in a set of different hardware and software infrastructure where the application user interface (UI) can be executed
• Application Server (aka Middleware), ranging from just one server up to a farm of them, where client requirements arrive through transport and message protocols (HTTP, SMTP, SOAP and other XML-based, etc)
• Back-end, a set of heterogeneous supporting infrastructures. We can find examples like databases (for persistence ends), or complex legacy systems on a mainframe infrastructure

The application server here plays a key role as a concentrator of low-level services (communication, security, etc), thus joining different channels in their access to enterprise back-ends
This approach brings Scalability, Centralized Security and Fault Tolerance. A better explanation of this approach is available in the same book, at http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnpatterns/html/ArcThreeTieredDistribution.asp

Model-View-Controller
We have already reviewed this behavioral architecture pattern at Starting with Model/View/Controller (MVC) Architecture Pattern (http://www.skyscrapr.net/blogs/solution/archive/2006/08/07/262.aspx). In brief words, this time the three components are

• The View, although it seems that we are talking about the Presentation layer of the 3-Layered architecture, or the Client of the 3-Tier architecture, this version of view just carry presentation logic without event handling. Such later responsibility belongs to
• The Controller, a component which receives Actor actions thru the View and motivates System responses in the same way envisioned in the Use Case document (a two column document enlisting stimulus/responses). These responses almost always involve
• The Model, the status of the system, its business entities and the business rules which govern itself

This pattern is very useful to comprehend and implement behavioral aspects of the user interface, and its relationship with the rest of the system. It permits keep low the coupling between UI technologies and business logic together with persistence mechanisms. A deeper discussion is available at http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnpatterns/html/ArcThreeTieredDistribution.asp