Learning JavaScript Design Patterns

MVC

MVC is an architectural design pattern that encourages improved application organization through a separation of concerns. It enforces the isolation of business data (Models) from user interfaces (Views), with a third component (Controllers) traditionally managing logic and user input. The pattern was originally designed by Trygve Reenskaug during his time working on Smalltalk-80 (1979) where it was initially called Model-View-Controller-Editor. MVC went on to be described in depth in 1995’s Design Patterns: Elements of Reusable Object-Oriented Software a.k.a the “GoF” book, which played a role in popularizing its use.

Smalltalk-80 MVC

It’s important to understand what the original MVC pattern was aiming to solve, as it has mutated quite heavily since the days of its origin. Back in the 70s, graphical user interfaces were few and far between, and a concept known as Separated Presentation began to be used as a means to make a clear division between domain objects that modelled concepts in the real world (e.g., a photo, a person) and the presentation objects that were rendered to the users screen.

The Smalltalk-80 implementation of MVC took this concept further and had an objective of separating out the application logic from the user interface. The idea was that decoupling these parts of the application would also allow the reuse of models for other interfaces in the application. There are some interesting points worth noting about Smalltalk-80’s MVC architecture:

• A Model represented domain-specific data and was ignorant of the user interface (Views and Controllers). When a model changed, it would inform its observers.

• A View represented the current state of a Model. The Observer pattern was used for letting the View know whenever the Model was updated or modified.

• Presentation was taken care of by the View, but there wasn’t just a single View and Controller—a View-Controller pair was required for each section or element displayed on the screen.

• The Controller’s role in this pair was handling user interaction (such as key presses and actions such as clicks), making decisions for the View.

Developers are sometimes surprised when they learn that the Observer pattern (nowadays commonly implemented as the Publish/Subscribe variation) was included as a part of MVC’s architecture many decades ago. In Smalltalk-80’s MVC, the View observes the Model. As mentioned in the bullet point above, anytime the Model changes, the Views react. A simple example of this is an application backed by stock market data. In order for the application to be useful, any change to the data in our Models should result in the View being refreshed instantly.

Martin Fowler has done an excellent job of writing about the origins of MVC over the years, and if you are interested in some further historical information about Smalltalk-80’s MVC, I recommend reading his work.