MVC in a three-tier architecture - TRANSLATED

A month back I wrote a post on architecting web and mobile based applications. In the post I spoke very technically about the MVC pattern and three-tier architectures. One of the comments I got on the post was from a very bright friend of mine who also works on educational technology and professional development, only from a senior management perspective. His comment was in really wishing he knew what I was talking about. And after reading the post again, I agreed that for a non-technical person the post would have been difficult to understand, I also felt there was good value in translating it for the non-technical person. Explaining the MVC pattern and three-tier architectures in this way would have great value to those who want (even need) to understand the web, mobile technologies and how these are put together. So this post attempts to answers that need... and if it works out, I may rewrite a number of my posts for the non-technical person.


Model-View-Controller

The Model-View-Controller (MVC) is a design pattern used to design the user interface and activities of a software application. In other words, what does a web page or mobile application look like and how does it work. How is the software designed so pictures, words, links and buttons show up, and what happens when someone clicks on a button or a hyperlink. The individual items of Model, View and Controller each serve a purpose; the Model is the business and related data and processes, the View is what is displayed to the end user and the Controller handles the events between what is displayed and how the business responds.

• The View is what is rendered (drawn) on the screen. How it is rendered is where the software part comes in. The technology (programming) behind rendering a View (or screen full of information) includes many options and approaches. Beyond a lot of formatting and graphic design, what makes the work behind the View is that there are many screens to that the software has to render a view. These screens come from different types of computers (PCs, Mobile, Tablets, Etc.), different browsers (firefox, safari, chrome, ie), different sized screens, Etc. Writing software for these different screens takes work and isolating the code into that responsible for only rendering the View greatly simplifies what can become complicated.
• The Model is the business logic or software that collects and retrieves any data required for the View. When data needs to be retrieved from or saved to the data storage it is the model which is responsible. The model can contain a lot of complicated business logic. As an example, someone submitting a credit card transaction may have only a few data fields and one button click on the view but the amount of different business activities (or software modules) that get utilized to complete the credit card transaction can be numerous and span different computers and businesses.
• The Controller responds to user events. The events can trigger changes or activities from both the View and the Model. As a simple example; a user enters their user credentials (user name, password) and clicks the log in button. The Controller then initiates a call to the Model which in turn executes the software required to find the user name and confirm the password... the Model then returns a call to the View with the pass or fail of the log in and the View re-renders itself with either a logged in user interface or the "forgot password?" user interface.

There you have it, simply put; the View is responsible for drawing the screen, the Model is responsible for retrieving and adding / updating information and the Controller is responsible for managing the events between the View, the end-user and the Model. Once you feel comfortable with your understanding of this MVC design pattern, move of to the next section describing the three-tier architecture. Hold off asking yourself how the Model-View-Controller (MVC) fits in the three-tier architecture for now. That will be discussed later.

Three-Tier Architecture

A design / concept of the three-tier architecture was created over 20 years ago, and was initially adopted when building client-server software. The idea being the personal computers on the network were the clients and the big computers on the network were the servers. And the clients made requests to the servers, the servers talked among themselves (business logic servers and database server) figured things out and then the servers responded back to the clients. This basic idea continues. Now the clients are web browsers and other devices, and the servers are web site servers, business logic servers and database servers.

Why so many servers? Performance, security, reuse, maintainability and understandability. There are actually other reasons to implement a three-tier architecture. I see these as the primary reasons;

1. Performance, security - Any interactive website with a significant amount of traffic could not be hosted on a single computer for performance reasons. The software needs to be constructed in a way where it can span multiple servers. The best way to have software span multiple servers is to modularize the software based upon its activity. Within a three-tier architecture modules would be constructed for the specific activities of user interface rendering, business logic, database reads and database writes. Each of these modules would be optimized for its activity and implemented across servers best suited to the modules performance needs. Another powerful reason for separating modules and hosting them on different servers is for security reasons. The closer a software module is to the storage of a piece of content (data, rich-media, documents) the stronger the security needs to be. It is also important to mention the idea of a cache, when building high performance web sites it is important to utilize a cache. The main idea of a cache is that it takes frequently requested content and makes it more quickly available to the web site.
2. Reuse, maintainability - modularizing software enables reuse and increases maintainability. The idea being that many modules can call one module to perform the same activity. As an example; saving both a bill to address and a ship to address is almost exactly the same activity, this should be done through a single module. This also eases maintainability, if you need to fix or update the address saving abilities of the software it only has to be done in one module.
3. Understandability -  understanding how a website application is put together, particularly when it spans multiple servers, becomes increasingly important as time passes. People change, business approaches change, features get added and updated. Having the IT Team easily understand how to enhance and maintain a website is greatly improved when the software is well organized and built in a modular way.

Building software in three-tiers provides the flexibility to organize the software to meet performance and business needs while it is operational. How the software is going to perform under user load is not always known until after the release of the software onto the internet. This is more true for web based software as performance will be determined by user traffic and users are unpredictable. Business needs will also change, so being able to alter the software with little to no impact to existing software modules is more easily done within a three-tier architecture. Well designed three-tier architectures are more easily understood and maintained than other approaches.

The MVC implemented in a three-tier architecture 

Figure 1. The MVC / 3-Tier Hybrid

How do these two come together. From a MVC perspective the View and Controller exists in the presentation tier and the model spans the business and data tiers. From a three-tier perspective this means the Model is broken into modules which are optimized based on their activity and for their ability to be reused and altered for new business opportunities. The Model will span the business and data tiers. The Controller and View exist in the presentation tier and this is also optimal for it allows the software developer to build, render and respond to user interfaces best designed for the different devices (internet browsers and mobile devices).

So how is all this best described from a non-technical perspective. We will start at the top and work our way down and back to the top again. Our scenario will include three activities. Arriving at a web site, logging into the site and adding a ship to address to a persons profile.

Scenario: A user wants to update their profile so they have separate ship to and bill to addresses.
Note: this scenario may not be as all websites handle these activities, it serves as an example to explain the MVC pattern and three-tier architecture.

Arriving at a web site
The user arrives at a website and the sites main page is displayed. The main page is rendered in the following manner;

1. Software in the Controller will determine the type of device browsing the website. Once the device / browser type is determined the Controller requests the correct View to render itself. Specific Views are built to service the different device and browser types.
2. The rendering of the View will make requests of the Model to fetch data (text, images, etc.) from the business and data tier modules. These modules will mostly fetch data from the Reads side of the data storage (see Figure 1. The MVC / 3-Tier Hybrid). For performance reasons, some websites will have these reads come from the cache. Many Views will also use style sheets and templates to help in their rendering.
3. All this activity takes only moments in a well designed website and once completed the View will be rendered and the user can view and interact with its content.

Logging into a site
After review of the sites main page, the user logs into their account. The process is managed is as follows;

1. The user types their email and password into the required text fields and clicks the associated button. This click event is intercepted by the Controller and decides the appropriate action. In most cases, some software (usually javascript) is run within the Controller to check the username and password are complete and follow some basic rules. If all is good the Controller will pass the email and password onto the Model as parameters for the email and password verification request.

2. The Model will take these parameters and make a request to a module built to handle user related requests to verify the email and password are valid.
3. The module dedicated to user requests will query the Reads side of the database modules to fetch the users password based on their email address provided in the parameter(s). 
4. If the password matches the module will pass TRUE back up to the Model, and the Model will request the View re-render itself with a valid login. This re-rendered View will often have additional menus for the user to perform additional actions not available to the non-logged in user.
5. If the password doesn't match the module will pass FALSE back up to the Model, and the Model will request the View re-render itself with an invalid login. This re-rendered View will again prompt the user for their email and password with the additional prompt of "Can't access your account?".

Adding a ship to address
Once the user has successfully logged in they will have the ability to edit their profile. The process of displaying their profile page and adding a ship to address would be as follows;

1. The profile View would make requests of the Model to fetch all the data required to render the persons profile data. This data fetching would occur via business and data tier modules built to handle the user related requests.
2. These requests would occur on the Reads side of the database modules and once completed the Model would request the View to re-render itself with all the users profile data.
3. Texts fields for the users ship to address would be presented and the user would complete the required fields. The user would then click a button to update their profile and save this new address to the database.
4. The click event is intercepted by the Controller and the appropriate action would be performed. Again, in most cases, some software (usually javascript) is run within the Controller to check the data entered follows some basic rules for accuracy.
5. The Controller would make the request of the Model to save the ship to address. The Model would make requests of the business and data tier modules specifically built to save address data.

6. The request to save this new address would occur on the Writes side of the database modules. Database writes are different than reads and this is explained in greater detail in a related post titled, "separation of database reads from writes". 
7. If the saving of data is successful two activities will occur; first, a confirmation will be sent back up to the Model, and the Model will request the View re-render itself with a confirmation of the data being successfully saved. Second, the data saved to the write side of the databases will be synchronized with the Reads side making it available for any subsequent read request.
8. If the saving of data is unsuccessful a return-code will be sent back up to the Model, and the Model will request the View re-render itself with correct error message. The user would correct the errors and the round trip of saving the data would occur again.

Why the hybrid?
Because building websites can be complicated, particularly when the site engages users and have a lot of content that can be targeted toward and created by users.  Why the hybrid of MVC and three-tiers? Two main reasons; First, because the MVC pattern does a great job of simplifying and managing the development of user interfaces over multiple devices and browsers, but it doesn't do a good job of defining how to build scalable server infrastructures. Second, The three-tier architecture does a great job of simplifying and managing the development of high performing, scalable, extensible and maintainable server infrastructures, but doesn't do a good job of defining how to build user interfaces across multiple devices and browsers. With a MVC three-tier hybrid you can utilize the best of both approaches without compromising either.