A Pattern Language for MVC Derivatives
Sami Lappalainen

Takashi Kobayashi

Aalto University
School of Science
Department of Computer Science

Tokyo Institute of Technology
School of Computing
Department of Computer Sciencesami.k.lappalainen@iki.fi

ABSTRACT

2.1

Choosing a suitable software UI-pattern for an application
can be hard and time consuming. There are multiple choices
available, some being a part of the so called Model-View-*(MV*) family of patterns. The aim of this study is to provide
a comparison of these patterns to help in the selection of asuitable pattern. We discuss the differences, pros and consof the three main patterns; Model-View-Controller, ModelView-Presenter and Model-View-Viewmodel. For this papera study of literature was conducted in order to understandand compare these patterns, then a simple pattern language
was visualised to aid in decision making.

One of the first patterns in the MV* family is the ModelView-Controller (MVC) pattern introduced at the end of
1970’s for the Smalltalk programming language by Trygve
Reenskaug [2]. The pattern was developed with the aim toseparate visual feedback, user input and application modelof each other [3]. The intent of all MV* patterns is to separate the aforementioned responsibilities to different objects.
In MVC the three separate objects are called Model, Viewand Controller. The relations between these objects has
been described in figure 1.

1.

INTRODUCTION

Creating an application user interface and binding it to theunderlying application logic involves many considerations
such as testability, maintainability, and modifiability of thesolution. Over time a number of software developmental
patterns have emerged to aid programmers solve problems
dealing with coupling user interface to application domain.

Model-View-Controller

The View component is responsible for instantiating the controller, displaying model data and forwarding input commands to the controller object. The controller object is responsible for handling user gestures and input and modifying
the model based on that. The model is responsible for holding data and notifying the view of changes in itself. There
are several minor variations that can be called the MVC
pattern. They differ mainly in the division of labor between
the controller and model.

For this research paper we have conducted a literature review on the Model-View-* (MV*) family of patterns using
the family definition outlined by Syromiatnikov and Weyns
in their research on MV* design patterns [1]. The purposeof this paper is to serve as an overview to MV* design patterns and propose a rough method for choosing the mostsuitable pattern based on application size and requirements.
The structure of this paper is the following; An overview ofthe patterns is given in chapter 2, part 3 contains patterncomparison and definition of the pattern language, part4 isa summary of study.

2.

OVERVIEW OF THE PATTERNSIn this section we give a brief overview of the four main MV*patterns; Model-View-Controller (MVC), Model-View-Presenter (MVP), MVP (Supervising Controller) and ModelView-ViewModel (MVVM).
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission. A preliminary version of this paper was presented in a writers’ workshop at the 2Xth Conference on Pattern Languages of Programs(PLoP). PLoP’XX, OCTOBER XX-YY, Allerton, Illinois, USA. Copyright20xx is held by the author(s). HILLSIDE 978-1-XXXXXX-XX-X

Figure 1: MVC pattern. Controller and View bothhave direct access to model. The controller handles
user input and changes the model. The view is responsible for observing changes in the model andupdating itself to reflect the changes.
The MVC pattern provides clear separation of concerns andmakes it possible to bind multiple different views to the samemodel. However, by separating the user input and view
into separate entities, it is a somewhat unsuitable pattern
for modern desktop user interface frameworks, that usuallycombine these responsibilities by using widgets for creatingrich user interfaces [4]. Testability is also of concern since theview needs to handle updating itself leading to untestablecode-behind, this can however be somewhat remedied byof testable code in the views code-behind.

Figure 2: MVC2 pattern. The controller has accessto model and view. It handles user input and decides
which view should render the request it received.
following Michael Feathers’ Humble Dialog box approachand creating a non GUI-class that has a one-to-one mappingof the view functions. This way the view can be substituted
by a mock and tested more thoroughly since the view has
no logic in the code-behind. [5] This approach somewhat
resembles the Presentation Model or MVVM architectures.

Figure 3: MVP (SC) pattern. The presenter has direct access to view and model. The view also has a 1way observer synchronisation binding to the underlying model. Presenter is responsible for handlingview state logic and calling business logic methods
on the model.

MVC has multiple derivations, most notable being the J2EE
MVC Model 2 as shown in figure 2, that was developed forJava web applications to address problems with the MVC
pattern. [6] The difference between MVC2 and MVC is thatthe controller is responsible for processing user input andmodifies the model and view accordingly. It then passes
the data to a view that renders the data. It provides aclearer separation of concerns, better testability and better
maintainability than normal MVC. It is also more suitable
for medium and large sized applications.
As shown by N. Delessy and E.B. Fernandez [7] The MVC
patterns can also be used for building secure web applications. By implementing several other security patterns andadding them to MVC, they created the secure MVC pattern. It allows users to securely access and modify sensitive
information in the model.

2.2

Model-View-Presenter

The Model-View-Presenter is a derivation of the original
MVC pattern published in 1996 by Taligent for C++ andJava. The goal was to improve the MVC separation of concerns and provide a way to facilitate automated unit tests
for the user interface [8]. There are two main variations ofthe pattern called Passive View and Supervising Controller.
The two variations have been visualised in figures 3 and 4.
The main difference when compared to the MVC-pattern isthat the presenter has a direct access to the view throughan interface, whereas in MVC the controller doesn’t know
about the view.
In Supervising Controller MVP the presenter is a slightly
modified controller that is responsible for updating the modeland notifying the view of changes in the model. The view
still holds a direct link to the model, making UI-testing hard.
This problem has been addressed in the passive view version
where the presenter acts as a connection between the viewand the model. The presenter acts on the model when it detects user input and updates the view through an interface
when the model changes. This also helps reduce the amountFigure 4: Passive View MVP pattern. The presenter has direct access to view and model. It is responsible handling view events and model changes.
The Supervising Controller pattern has a similar testability
footprint as MVC but it provides a way to handle view state
logic without extra fields in the model.
Passive View MVP displayed in figure 4 was developed toaddress the issues of testability in MVP (SC) and MVC. It
contains a presenter that handles user input and communication between the view and model. It also handles updating
the view through an interface defined by the view. This removes the coupling between view and model and allows fora larger testability footprint.
The benefit of the passive view pattern is high separation ofview and model, high testability and flexibility in divisionof responsibilities. However, it suffers from low re-usability
and separation of concerns since the presenter is responsible
for updating the view. This may also affect the complexityof code and hamper maintainability [1]. The Passive View
and Supervising Controller MVP patterns are suitable forall platforms. [9]2.3Model-View-Viewmodel

Model-View-Viewmodel is a derivation of Presentation Model,
which is a further derivation of the MVP pattern, introducedPattern

Project size

Separationof Concerns

Codecomplexity

Modifiability

Testability

Requiresviewsynch.

Platform

MVC

Small/Medium

FairLow

Low

Fair

Yes

Web/MobileGood

Medium/HighLow

Good

No

WebFair

HighHigh

Fair

Yes

AllGoodHigh

High

GoodNoAll

Good

Medium/High

Low

Very good

Yes

All

MVC2
MVP (SC)MVP (PV)
MVVM

Medium/EnterpriseMedium/Enterprise
Small/Medium/EnterpriseMedium/Enterprise

Table 1: Studied pattern characteristics and differencesin 2004 by Martin Fowler [10]. The pattern aims to decouple the view and viewmodel even further by introducing databindings between the view and viewmodel. The aim of thepattern is to enforce separation of concerns, support multiple
views on the same viewmodel and allow unit testing on theUI. The viewmodel works as an abstract of the model andthus allows decoupling view and model as shown in figure 5.

By studying literature four defining features could be found
for the patterns; separation of concerns, code complexity,modifiability and testability. Three more characteristics werechosen to aid in making a decision based on project requirements; platform, project size and framework synchronisation
requirements. By using these seven characteristics a table 1was constructed to display differences in the patterns.

The viewmodel works as a binder between the view and themodel. It holds information about the view state, allows
interaction with the model, handles view logic and notifies
the view of changes in the model and view state.

Recommended project size was defined to be either small,medium or enterprise. Small projects were defined as small
tools or single view programs where the use of complex UIpatterns such as MVVM might make the application more
complex than needed for the task. Medium applications areprograms that require multiple views and models, usuallycommercial applications that require testing before delivery to the customer and benefit from the added complexity of some patterns. Enterprise applications are programs
that require extensive and thorough testing, vast amountsof complex models and views.

Figure 5: MVVM pattern. The viewmodel is responsible for calling model methods and works as aproxy of the model for the view. The view is boundto the viewmodel through observer synchronisation.
The advantage of the MVVM pattern is high testability andlow amount of logic in the views code-behind. It also allows the UI to be unit-tested since the view just binds tothe viewmodel. The disadvantages of the pattern are for example; high complexity for small projects, debugging databidings during development due to their imperative natureand performance issues caused by excessive amounts of databindings [11]. The pattern is suitable for desktop, mobile
and web development, but mainly when using a frameworkthat provides native data-bindings between view and viewmodel.

3.

Separation of concerns is the principle of dividing a program into separate parts that address different aspects ofthe program. In our scenario the concern is to separate userinterface, input and business logic from each other. MVP(PV), MVC2 and MVVM patterns achieve higher separation of concerns [1] and were therefore assigned a higherscore than for MVC and MVP (SC).
Code complexity was based on the amount of work requiredby a programmer to couple the different parts together andthe amount of solution elements needed due to pattern usage. MVP scores lower than the other two patterns since it
requires programmers to write more code to implement view
updates manually in the presenter, whereas MVVM uses abinding system for coupling the views to the viewmodel andMVC uses observer synchronisation to inform the view ofchanges in the model [9] [12].
Modifiability is the ease of assigning different roles for different components. The MVC, MVC2 and MVVM patterns
don’t allow as much choice in this by definition. Whereas
the MVP patterns allow a leaner separation of concerns anda thus a greater modifiability [13]PATTERN LANGUAGE FOR MVC DERIVA- Testability was ranked based on the amount of testable code
each of the patterns allowed. A lower level of coupling
TIVES

Figure 6: A pattern language for MVC variants
and logic in views allows for a larger testability footprint.
MVVM achieves the highest testability score by allowing
programmers to write logic completely independent of theview [10] [13]. The MVP (PV) pattern allows for a large
testability footprint by handling view updating through aninterface but still requiring some minimal view logic. MVC2
achieves quite a good testability footprint, almost at thelevel with MVVM and MVP. MVC and MVP (SC) requireview logic for communicating with the model, thus scoring
lowest on the testability scale.
MVC, MVP (SC) and MVVM require observer synchronisation for coupling the view to the model or viewmodel. Especially in the case of MVVM this can cause a large amountof code overhead which must be taken into account whenchoosing a pattern when a framework has already been chosen for the application. [10]Due to low depth of interaction, the MVC patterns are notwidely supported by desktop frameworks. However, MVC iswidely supported in web and mobile applications, whereas
MVC2 is mainly limited to Java web applications . All theother patterns can be used in web, desktop and mobile environments.
Using table 1 as a reference the simple pattern language
in figure 6 can be developed. Due to the improvements to
MVC achieved in MVC2, it has been added to the patternlanguage chart, especially since it enables use of MVC on
modern medium and large web applications.
From the figure we can note that MVVM and MVP arehighly recommended for medium and large applications on
almost any platform. MVC is a versatile pattern that can beused in small and medium projects, but with the adaptationof MVC2 it can also be used in large projects requiring quite
extensive testing and a more distinct separation of concerns.
The MVP (SC) pattern is a good upgrade from MVC, since
it offers higher modifiability regarding controller responsibilities.

4.

SUMMARY

The Model-View-design patterns are a great and establishedsolution for solving the problem of separation of user interface, user input and application domain in an application.
These patterns have multiple differing characteristics thatmake them suitable for different types of applications on
multiple platforms. The MVC-pattern, especially the MVC2variant, is suited well for a wide range of web applicationsof all sizes while the MVVM and MVP patterns are viablechoices for all platforms rich user interfaces, high testability
and long term maintainability are required. The final decision of a pattern should be well grounded on application
requirements, framework and the use case at hand.
It should also be noted that since these patterns offer someamount of flexibility, the most suitable pattern for a projectmight be found somewhere in-between these.

5.

REFERENCES[1] Artem Syromiatnikov and Danny Weyns. A Journey
through the Land of Model-View-Design Patterns.
Software Architecture (WICSA), 2014 IEEE/IFIP
Conference on. IEEE, 2014.
[2] Trygve Reenskaug. MVC Pattern Language. 2003.
[Online; accessed 15-January-2017].
[3] Steve Burbeck. Applications programming insmalltalk-80 (tm): How to use model-view-controller(mvc). Smalltalk-80 v2 5, 1992.
[4] Hans Rohnert Peter Sommerlad Frank Buschmann,
Regine Meunier and Michael Stal. Pattern - Oriented
Software Architecture; A System of Patterns. John
Wiley and Sons, 1996.
[5] Michael Feathers. The Humble Dialog Box. ObjectMentor, 2002.
[6] John Crupi Deepak Alur and San Malks. Core J2EEPatterns Best Practices and Design Strategies.
Prentice Hall PTR, 2003.
[7] N. Delessy and E.B. Fernandez. The Secure MVC
pattern. July 23-27, 2012,. First InternationalSymposium on Software Architecture and Patterns, inconjunction with the 10th Latin American andCaribbean Conference for Engineering andTechnology, Panama City, Panama.
[8] Mike Potel. MVP: Model-View-Presenter the Taligent
programming model for C++ and Java. Taligent Inc,1996.
[9] Microsoft. The Model-View-Presenter (MVP) Pattern.
[Online; accessed 05-January-2017].
[10] Martin Fowler. Presentation Model. 2004. [Online;accessed 10-January-2017].
[11] John Gossmann. Advantages and disadvantages ofM-V-VM. 2006. [Online; accessed 13-January-2017].
[12] Steve Ng and Bimlesh Wadhwa. A Pattern Languagefor Mobile Application Development. 2014.
[13] Lou Tian. A Comparison of Android Native App
Architectures - MVC, MVP and MVVM. September
2016.