Model-View-Controller (MVC) Architecture

The MVC Model

Haphazard design can be tolerated on small projects but as code size increases beyond a few hundred lines, particular attention needs to be paid to how the code is structured. Consider the two approaches, below. In the first approach, all the software entities (A,B,C,D) talk to one another. In graph theory, we would call this a complete graph. In the approach shown on the right, the number of high level entities is fewer. Meanwhile, communications is also more restricted, with only one entity (C) having links to the others.

Software Architecture

As code size increases, the approach shown on the left will become increasingly more problematic because the programmers who own each of these entities will be forced to build interfaces to most other entities in the system. Meanwhile, debugging will become more difficult as execution flow will bounce from one object to another in an unpredictable pattern. To avoid these pitfalls, there are many different approaches to building a modern, software architecture. In this course, we will describe one popular approach known as Model-View-Controller (MVC). The three most important features of this architecture are:
  1. The Model and View are separate and distinct software entities. While the View describes what the user sees, the Model typically uses a different set of data (with different datatypes than the Model) to represent what the computer sees;
  2. The Model and View classes do not directly communicate with each other - they use the Controller entity as a go-between;
  3. The Model, View, and Controller are the only highest-level entities. Each has strict rules about what functionality it can perform. 

We will now describe this approach in more detail.

The MVC Model

MVC ArchitectureThe MVC architectural model for large software applications is one of many popular, modern architectural approaches used in the real world today. It is also the one most favored by Apple. Less important than the particular architectural approach taken is that one is used at all. Generally speaking, a good architectural model can dramatically reduce both code size as well as app complexity. Content from this section is taken mostly from a larger article on MVC architecture which can be found here.

MVC Overview

The MVC architectural model is made up of three layers: the Model, the View and the Controller

  • The Model

    This represents the internal (computer's) view of the app. Most of the data (including state information) should be stored here. Most of the code for the Model will consist of the model objects and their methods. However, if the app communicates with the outside world (the Internet or some other entity), this networking code should also be placed in the Model. Also, any code related to persistence should be placed here as well. 
  • The View

    The View layer is the User Interface of your app. Often GUI objects derived from a library such as JavaFX may make up large parts of this layer. Architects typically design the View layer to make as many of the View objects reusable as possible across apps. Every attempt should be made to minimize (or ideally avoid) interaction between the View and the Model layer. The View should not contain any business logic or any other logic not related to the User Interface (UI).
  • The Controller

    The Controller mediates between the View and the Model. It contains the business logic of the app and, as such, can be considered the centralized brain. In more sophisticated apps, a formal 
    protocol is often used to communicate between the Controller and the Model or View. As events occur in the View or Model, they typically inform the Controller to keep it up to date.

An MVC Architecture for Tic-Tac-Toe

Now consider what a Tic-Tac-Toe app might look like if implemented using an MVC approach:

MVC Model

Although the image, above, does not show the code in the View and Model classes, the main point to understand is how the View and the Model are different. While the user sees X's, O's, and blanks, the computer sees -1, 1 and 0. 

Variations of MVC

There are many possible software architectural models other than MVC. Software architectures, in general, are a controversial topic - the stuff of religious wars. Even within the MVC religious sect, there are variants. For example, in the version shown below, the Model serves as the central communications point instead of the Controller in the architecture. This variation which came from the Wiki on MVC is not the mainstream view of how MVC should work. Regardless, even in this version, the important point to consider is that the three main entities do not all talk to each other.

Alternate MVC Architecture