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): 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


 


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 (7)
  1. Hamza Khalid says:

    Most of the people think that 3 Tier architecture, three- Layer architecture and MVC . all are same….

  2. Muthu says:

    i want 2 clear define with 3-tier,3-layer and MVC

  3. Ericz says:

    bout the 3-tier architecture layers. . need examples. . . need help

  4. Raja says:

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

  5. Nik says:

    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.

  6. Neeraj Ojha says:

    really a goof Article. it nicely describe the difference amongst the three well known terms.keep it up!!!

  7. Jayprakash Bharti (vesit) says:

    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 ?"

Comments are closed.

Skip to main content