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

  • Article

 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