3-Tier, 3-Layer, MVC: a Trio of Famous Trios

 Contemporary  applications are being based on three popular architectural approaches. They are

  • 3-layered architecture
  • 3-tier architecture
  • Model-View-Controller architecture

There exists certain degree of confusion between all the three approaches. Mostly the first two are often referred as if they were the same one (see at Wikipedia). This can happen, possibly, because the three approaches aren't antagonistic. Actually, is pretty possible to find applications where the three are present. So let's dedicate some words to each of them

 

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): https://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 https://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 (https://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 https://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnpatterns/html/ArcThreeTieredDistribution.asp

 

Conclusion

As said above, these three approaches allow us a better understanding and organization of components. Both logical and physically speaking. Although they help us gain different features like Reusability or Scalability, they can perfectly be present in a same implementation

Comments

  • Anonymous
    November 19, 2006
    Most of the people think that 3 Tier architecture, three- Layer architecture and MVC . all are same....

  • Anonymous
    November 26, 2007
    i want 2 clear define with 3-tier,3-layer and MVC

  • Anonymous
    February 26, 2008
    bout the 3-tier architecture layers. . need examples. . . need help

  • Anonymous
    April 22, 2008
    You can see a N-tier architecture example with downloadable source code at http://www.dotnetfunda.com/articles/article18.aspx

  • Anonymous
    June 04, 2008
    can you please check links given here , it is not working ... It will be great if this is been make working other wise this topic will useless as detail given here is not enough for understanding.

  • Anonymous
    February 25, 2010
    really a goof Article. it nicely describe the difference amongst the three well known terms.keep it up!!!

  • Anonymous
    November 19, 2010
    Can any clear my Confusion ???? "Is it necessary to separate class in Business layer & data access layer respectively for each class in Presentation layer ? If YES then why ?"