Smalltalk was the incubator for Model-View-Controller and also played a role in Model-View-Presenter. Photo by Joey deVilla.
Original publication date: 2020-10-29.
Big Ball of Mud, spaghetti code, technical debt. Easily some of the least desirable terms to describe our applications.
With modern web applications taking care of more and more system concerns as time progresses, we find ourselves looking for battle-hardened, proven practices that have stood the test of time.
Does it even makes sense to speak of software architecture for the front-end or is it a pipe dream? It turns out that the challenge of maintaining a complex front-end is a problem that was identified at least as early as the 1970s.
Join me, as we dust off the history books and discover the origins of the Model-View-Presenter design pattern from a modern web perspective.
Model-View-Controller
Model-View-Controller (MVC), the older brother of Model-View-Presenter, was first introduced for the programming language Smalltalk by Trygve Reenskaug in the 1970s. Back then, a fair amount of logic was required just to capture user input. This was handled by the controller, and a Model-View-Controller triad existed for every single user control on the screen.
As the web emerged during the 1990s, the interest in Model-View-Controller increased because of WebObjects for NeXT and Java. It was further popularised in the 2000s by server-side web frameworks such as Struts and Spring (Java), Django (Python), Rails (Ruby), and ASP.NET MVC (C# and friends). Usually, the framework routed requests to the relevant controller by using a so-called front controller.
Model-View-Presenter
Figure from the paper “MVP: Model-View-Presenter — The Taligent Programming Model for C++ and Java” by Mike Potel.
In the early 1990s, Model-View-Presenter (MVP) was first described and used with C++ by Taligent. In the late 1990s, Taligent introduced it to the Java platform and Dolphin adapted it to their Smalltalk UI framework.
In the late 2000s, Microsoft began advocating Model-View-Presenter for developing rich applications with .NET such as Windows Forms, Silverlight, SharePoint, and ASP.NET.
Several variations of the Model-View-Presenter pattern emerged through the first decades it was used. To learn about the differences, read the material on the Taligent and Dolphin Smalltalk variants in the article “Interactive Application Architecture Patterns” by Derek “Aspiring Craftsman” Greer.
JavaScript
A handful of examples from the first generation of UI frameworks for JavaScript.
In the late 2000s and early 2010s, the first generation of UI frameworks—such as AngularJS, Backbone, Dojo Toolkit, Ember, JavaScriptMVC, and Knockout—introduced the Model-View-Controller and Model-View-View Model (MVVM) patterns to client-side web development. This allowed us to separate the presentational logic from the application state while keeping the horizontal software layers synchronised.
The current generation of UI frameworks such as Angular, Aurelia, Dojo, Inferno, Preact, React, Svelte, and Vue are component-based. They focus on UI widgets but leave the details of separating the presentational layers from the rest of the application up to us.
Model-View-Presenter in modern web applications
Model-View-Presenter can be fitted for the Angular platform. Figure from my talk “Model-View-Presenter with Angular” (slides).
Identifying that the popular UI frameworks have no design pattern of choice for separating our applications into horizontal software layers, we have to pick one and apply it on our own if we want to enforce separation of concerns.
Drawing from the wisdom of the React community, I have described a variant of the Model-View-Presenter pattern that is well-fitted for the Angular platform. Read "Model-View-Presenter with Angular" to learn more.
Top comments (0)