Architecture Patterns: Model-View-Controller

Model View Controller (a.k.a. MVC) is one of the most misquoted and argued architecture pattern I have ever seen. It is incredible the number of blogs, articles, and different implementations out there, but still, the confusion reigns and also many developers experienced and not, struggle to explain it and find it difficult to understand.

is the overuse/misuse of the term Controller. Plus, most of the times diagrams are misleading because it’s not clear if they are UML diagrams and if so, what kind of diagram? What is the meaning of each arrow?

In this article, I will try to explain it with a historical approach which I personally think it helps a lot to better understand where the term Controller comes from and how the pattern evolved.

The MVC in its original form was first introduced with Smalltalk-76 by its creator Trygve Reenskaug in the 1970s and later implemented in Smalltalk-80 in the 1980s, but formally explained for the first time in an article on The Journal of Object Technology in 1988.

MVC was born as a GUI (Graphical User Interface) architecture style and at that time things were clearly different than today, just think of a screen with black and white UI, GUI was not complex and probably didn’t have much logic either.
The concept of a framework of reusable UI components was still far from what we have today and UI elements such as Buttons, Text, Checkboxes were just able to draw themselves, they didn’t have any capability to detect inputs from a keyboard or a mouse which was the job of the Controller.

MVC Concept

The main purpose of MVC was to introduce a clear separation between the data layer and the presentation layer, making the domain objects (model) unaware of the presentation objects (views and controllers). In order to achieve that, it uses the Observer pattern to support multiple presentations (Observers) of one single domain model (Observable).
Later, Smalltalkers also realized this way they could make reusable widgets (a.k.a. controls as View-Controller pairs), that could be used as out-of-the-box solutions to build GUIs for future applications (kind of what we have today).

  • View is a widget on the screen surface, it is only able to draw itself. Not able to handle inputs.
  • Controller is responsible to handle user interactions/inputs such as keyboard or mouse events for a single View.
  • Model is the data layer, responsible for managing the business logic and data sources such as databases or network APIs.

We can summarize 3 key points:

  1. Separation of concerns between UI and Model
  2. GUI divides input and output handling by pairs <View, Controller>. There is no direct communication involved with each other.
  3. Model is independent and loosely coupled with Views and Controllers (Observer Pattern)

MVC Evolution

Like anything else, also MVC evolved into different variations, such as the Classic MVC or Application Model MVC and different implementations such Passive Model or Active Model in order to satisfy all the different needs coming from the increasing complexity of GUIs and application logic. But the variations share all the same concept, which has never changed.

Classic MVC

Active Model View Controller Communication diagram

The diagram above is a UML Communication diagram which shows how MVC components collaborate, describes the behavior of the components involved. Bear in mind it’s not a Class diagram. E.g. there is no direct communication involved between a View and its Controller.
In simple words, the controller receives inputs from the user, commands the model as appropriate, the model performs some business logic, changes its state and raise an event to notify that to any view listening to that event, the responding view asks relevant data to the model and accordingly changes its display state.

The example above is also known as Active Model MVC, where it is Model responsibility to notify a state change.
Instead, in the Passive Model MVC, the Controller commands the Model and is also responsible for notifying the View of a state change. Then, the view queries the Model as usual to retrieve the new state.

Passive Model View Controller Communication diagram

The “Classic” MVC is the first implementation of the pattern as it was formalized by Smalltalk. It is really basic and simple, it achieves the main purpose the pattern was introduced for in the first place. It suits very well for simple GUI with no much UI logic involved.

Application Model MVC

With the increasing complexity of the UI logic, the Classic MVC showed its first limits.

Where should the UI logic belong?

  1. In the Model? This would break the separation of concern principle. The Model would be responsible for either business logic and UI logic. Moreover, it would make the Model depend on the View as well. Difficult to reuse and maintain.
  2. In the Controller or the View? Moving any UI logic into either the View or the Controller would work, but it would make the widget not generic anymore, plus it would break the single responsibility principle. The Controller is responsible to handle inputs and the View is responsible to draw itself.

Smalltalkers came up with a new solution, a component with the only responsibility to deal with UI logic and able to operate between the View/Controller pairs and the Model, called the Application Model.

Application Model MVC Communication diagram

The only difference is that all the communication passes through the Application Model from Controller to the Model and back to the View in the same way it works for the Classic MVC. Application model behaves as a proxy. It introduces, of course, an extra layer but it keeps the UI logic and the business logic well separate and the Model still independent from the UI.

With the creations of more generalized frameworks for building GUI for client-side applications, UI widgets became more and more reusable and powerful combining the View and the Controller capabilities in one single reusable out-of-the-box solution like today.

It is easy to see how the MVC at some point evolved into MVP…

MVC in Android

In many blogs or usual StackOverflow answers, I often read that Android has been designed thinking of MVC, with the XML layout being the View, Activities or Fragments being the Controller… or both View and Controller. I think this is nonsense.

Implementing the MVC exactly as it was thought by Smalltalk it is not really possible since today Android framework provides widgets which are capable to handle user inputs. The role of the Controller is gone.

What we can do is to apply the same principles, the communication and data flow to build an application that makes usage of MVC in a more modern way:

  • The Activities, Fragments, and Views should be the View in the MVC.
  • The Controller and Model should be separate classes that don’t extend or use any Android class.
  • The View and the Controller depend on each other, but for testing purpose and to respect the Dependency inversion principle, the View should implement an Interface and the Controller should reference that and not the concrete class directly.

As a reference, in my GitHub there is a basic sample of how to apply MVC in Android, feel free to check that out.

Class diagram of an implementation of MVC


Android Developer @letgo