Chapter 2: The MVC pattern within a three tier architecture[edit | edit source]
Chapter Author: Peter Rawsthorne[edit | edit source]
Evidence: showing your knowledge[edit | edit source]
Section 1: Model-View-Controller[edit | edit source]
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 Challenge[edit | edit source]
To explain the Model-View-Controller (MVC) pattern within a different analogy. Understanding the MVC pattern can have a steep learning curve which can be lessened by conceptualizing the role of each element. During this chapter section try to understand the MVC within a different analogy.
Model-View-Controller (MVC) explained[edit | edit source]
The View[edit | edit source]
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[edit | edit source]
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[edit | edit source]
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.
The design pattern[edit | edit source]
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.