MVC in a three-tier architecture

The increase of web and mobile software development can get one thinking about how to best design and architect an application for these platforms. The two proven approaches that find themselves into this discussion are the Model View Controller (MVC) pattern and the three-tier architecture. This post is meant to describe these two approaches and how I believe they should work together and why.

Model-View-Controller

The MVC Pattern

The MVC pattern provides very well when building applications that are to be consumed by many different platforms (it also provides well when you are building for a single platform). When targeting platforms that are mobile devices, tablets and different browsers on different operating systems the MVC pattern is a proven approach. The MVC pattern separates different parts of rendering the User Interface (UI) into modules, so the code for rendering the actual interface is separated from the code that manages the data which is also separated from the code that handles the user events.

Three-Tier Architecture

The 3-tier Architecture

The three-tier architecture separates the deployment of software components into three logical layers. These layers include;

• Presentation Tier - responsible for rendering the User Interface
• Business Tier (or Logic Tier) - responsible for processing the business rules or logic
• Data Tier - responsible for interacting with the data storage system

This separation is for a number of reasons which include maintainability, reuse and deployment. When software is modularized and separated into these three-tiers, the modules can be deployed to different server infrastructures for security, scalability and performance. And the deployment approach can change as the need requires. The modules are also easier to maintain and reuse when they are each built for a discrete purpose.

The MVC implemented in a three-tier architecture

The MVC - Three Tier Hybrid

When the MVC and three-tier approaches are brought together the View and Controller are considered the presentation tier, the Model exists in the business tier (and has access to many business and data tier modules). To a certain extent the Model could span both the business and data tiers. It is this authors view that the Model would not exist in the layer of the data tier that is specifically Data Access Layer (DAL) code including SQL or code optimized for DAL within a cached environment.
Some important aspects of this diagram include is the separation of data reads from writes. Writes take considerably more data storage resources than do reads, so separating these into different physical data stores can have huge benefit. It should also identified that the modules for the business and data logic can be numerous. And these exist for maintainability and scalability purposes. It is also reasonable that the Model may access the Data Tier directly without going through a Business Tier module.

Why the hybrid?
The MVC pattern does not describe how to best design the data access and how to manage the complexity that can occur within the business and data tiers. As the internet has become more open and further entrenched in business processes, the demand to access the business tier without the presentation tier has increased. The creation of Business Tier modules allows for other approaches (such as REST) to access business logic from other sources, enabling business-to-business interactions and innovations.