< PreviousChapter 5: State of the Art70Chapter Contents5.1 Model-View Separation Patterns .......................................... 715.1.1 Model-View-Controller (MVC) ...................................... 725.1.2 Hierarchical Model-View-Controller (HMVC) .................... 775.1.3 Presentation-Abstraction-Control (PAC) ......................... 835.1.4 Model-View-Adapter (MVA) ........................................ 885.1.5 Model-View-Presenter (MVP) ...................................... 935.1.6 Model-View-View-Model (MVVM) ................................. 975.2 User Interface Utility Patterns ............................................. 1035.2.1 Presentation Model (PM) ........................................... 1035.2.2 Data Binding (DB) .................................................... 1045.2.3 Negligible View (NV) ................................................. 1055.3 Approaches in Practice ...................................................... 1075.3.1 All-In-One Frameworks ............................................. 1075.3.2 Separation-of-Concern-Based Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . 109Model-View Separation Patterns715.1 Model-View Separation PatternsModels are not right or wrong; they are more or less useful. — Martin Fowler, “Analysis Patterns: Reusable Object Models”In this section, the major Model-View Separation Patterns are checked and evaluat-ed against our Requirements Suite (see Section 4.2 on page 61). For the general background to patterns see [Alexander et al. 1977], [Alexander 1979], [Lea 1994], [Ga-briel 1995a], [Gabriel 1995b], [Hanmer 2012] and [Bauer 2015]. For some background in Software Architecture patterns see [Gamma et al. 1994], [Coplien & Schmidt 1995], [Vlissidis et al. 1995], [Martin et al. 1998], [Martin et al. 1998], [Foote et al. 2000], [Smith 2012], [Starke & Hruschka 2014] and [Eilebrecht & Starke 2014]. For an over-view of Model-View Separation Patterns see [Alpaev 2006], [Syromiatnikov 2014] and [Borini 2017]. For details on Model-View Separation itself, see [Parr 2004].The major focus here is on the following particular requirements, as all other requirements are not reasonably applicable in this context and hence are skipped: ■[REQ-F3] Separation of Mask, Style, and Behaviour ■[REQ-F4] Separation of Controls, Interactions, and Events ■[REQ-F5] Dialog-Level Structuring ■[REQ-F6] Dialog Life-Cycle and States ■[REQ-C1] HTML5 Single-Page-Application Approach ■[REQ-C3] Potential Offline Operation ■[REQ-C4] Near-Real-Time Updates ■[REQ-A1] Separation of Model, View, and Control ■[REQ-A2] Distinguished Presentation Model ■[REQ-A3] Dialog Instantiation and Reusability ■[REQ-A4] Dialog-Level Component-Orientation ■[REQ-A5] Hierarchical Dialog Communication ■[REQ-A6] Transitive Dialog Communication ■[REQ-D2] Hierarchical Development-Time Dialog De-Composition ■[REQ-D3] Distributed Orchestration of Run-Time Dialog Re-Composition ■[REQ-D4] Event-Driven Architecture ■[REQ-E1] Potential Web Technology Independence ■[REQ-E4] Head-Less Run-Time Testing ■[REQ-E5] Massive Dialog ScalabilityChapter 5: State of the Art725.1.1 Model-View-Controller (MVC)Pattern OriginThe classical Model-View-Controller (MVC) [Reenskaug 2003] software architecture pattern was originally introduced in 1979 to Smalltalk-76 by [Reenskaug 1979a] [Reenskaug 1979b] [Reenskaug 1979c]. It was then implemented, most prominent-ly, for the Smalltalk-80 class library. In [Krasner & Pope 1988], MVC was finally ex-pressed as a general concept, the first time. Finally, [Burbeck 1992] documented the MVC variant in Smalltalk-80 versions 2.0 and 2.5. Historical notes can be found in [Reenskaug 2012].Further information on special aspects of and perspectives on MVC can be found in [Sasine & Toal 1995], [Lynch 2002], [Lindberg & Rydin 2002], [Veit & Her-rmann 2003] [Sauter et al. 2004], [Hansen & Fossum 2005], [Lucassen & Maes 2006], [Weitzman 2006], [Cherdron et al. 2007], [Farn 2007], [Li & Chou 2008], [Deacon 2009], [Sridaran et al. 2010], [Kratzer & Bottcher 2010], [Taraghi & Ebner 2010], [Delessy-Gassant & Fernandez 2012], [Jivani et al. 2013], [Bolarinwa 2013], [Hameed et al. 2014], Figure 5.1: Model-View-Controller (MVC) PatternModelViewControllerOutputDevicesInputDevicesother controllersuperview****read/updateread(/update)rendernotifyread/updateupdatedupdatedXComponentKnowledgeRelationshipRun-TimeCallRun-TimeCall-BackupdateModel-View Separation Patterns73[Pierce 2014], [Cemus et al. 2015], [Ollsson et al. 2015], [Ocariza et al. 2015], [Jailia et al. 2016], and [Aniche et al. 2016].Pattern Description[Krasner & Pope 1988] tells the basic idea: “Model-View-Controller (MVC) program-ming is the application of three-way factoring [of a piece of software], whereby objects of different classes take over the operations related to the application do-main (the model), the display of the application’s state (the view), and the user in-teraction with the model and the view (the controller). “Figure 5.1 on page 72 shows a summarizing illustration of the MVC pattern. A pair of Controller and View Components, each knowing each other, is the core of the pattern. Their instantiation happens via the View Component, which is at-tached to a hierarchy of View Components, creates its corresponding Controller Component and attaches to an underlying and already existing Model Component [Burbeck 1992]. There is a one-to-one relationship between Controller and View and a one-to-one link from Controller to Model and from View to Model Component. Model Components have no knowledge about Controller and View Components at all and can be linked from any num-ber of Controller and View Components in parallel. The Model Compo-nents are implementing the Observable pattern to allow Controller and View Components to react to Model Component updates.Both [Reenskaug 1979c] and [Krasner & Pope 1988] state that the View Component not only reads from the Model Component but is also allowed to update it directly. However, no known hint in the literature indicates the reason for this. Instead, even all found Smalltalk-80 code examples of View Components never update the Model Component directly. It is always the Controller Component which updates the Model Component in practice. So, it is assumed that the original MVC pattern conceptually allowed more than the Smalltalk-80 implementation later actually used.It should be noted that in the original MVC, there is a clear separation between the input devices and the output devices. As a result, one can even consider the Controller to be a Supervising Controller [Fowler 2006a] here. As a consequence, the original MVC pattern is more suitable to implement Graphical User In-terface (GUI) platforms and frameworks at a lower level and less suitable to structure the classes of an application at a higher level. This lower-level GUI focus also manifests in the fact that in the original Smalltalk-80 MVC the Controller Components have to cooperate to not conflict on access to the input devices [Burbeck 1992] and that the input devices then were polled [Shan 1989], while today GUI platforms always can leverage events of the underlying Op-erating System and easily support an arbitrary number of non-conflicting attached event listeners.Today, the name Model-View-Controller (MVC) is attached to many ap-proaches, which usually only loosely follow the concept of the original Smalltalk-80 MVC pat-tern.MVC is a lower-level GUI pattern (Widget-level) and not perfectly suitable at the Dialog-level.Chapter 5: State of the Art74The Model Components in MVC can be either Passive Models or Active Models [Burbeck 1992]. A Passive Model has no Observer functionality, and hence the Con-troller Component here has to notify the View Component each time it updated the Model Component. An Active Model has the Observer functionality and auto-matically can notify the View Component each time it was updated (by either the Controller Component or any other Component in the system).Pattern EvaluationThe evaluation of the Model-View-Controller (MVC) software architecture pattern against the subset of our Requirements Suite (see Section 4.2 on page 61) one can find in Figure 5.2 on page 74. ■[REQ-F3] Separation of Mask, Style, and Behaviour: VERY GOOD: MVC clear-ly distinguishes between View and Controller Components, so inherently separates at least the Mask and Style from the Behaviour. Whether Mask and Style are also separated is not addressed by MVC, but at least not ex-plicitly prohibited and hence also possible.0%1-19%20-39%40-59%60-79%80-99%100%NOT AT ALLVERY POOR POORACCEPTABLEGOODVERY GOODPERFECTNDNA0123456REQ-F3Separation of Mask, Style, and BehaviourREQ-F4Separation of Controls, Interactions, and EventsREQ-F5Dialog-Level StructuringREQ-F6Dialog Life-Cycle and StatesREQ-C1HTML5 Single-Page-Application ApproachREQ-C3Potential Offline OperationREQ-C4Near-Real-Time UpdatesREQ-A1Separation of Model, View, and ControlREQ-A2Distinguished Presentation ModelREQ-A3Dialog Instantiation and ReusabilityREQ-A4Dialog-Level Component-OrientationREQ-A5Hierarchical Dialog CommunicationREQ-A6Transitive Dialog CommunicationREQ-D2Hierarchical Development-Time Dialog De-CompositionREQ-D3Distributed Orchestration of Run-Time Dialog Re-CompositionREQ-D4Event-Driven ArchitectureREQ-E1Potential Web Technology IndependenceREQ-E4Head-Less Run-Time TestingREQ-E5Massive Dialog ScalabilityREQUIREMENT ATTAINMENTNOT DETERMINABLENOT APPLICABLEFigure 5.2: Evaluation Results of Model-View-Controller (MVC) PatternModel-View Separation Patterns75 ■[REQ-F4] Separation of Controls, Interactions, and Events: VERY POOR: MVC clearly distinguishes between the output-focused View and input-focused Controller Components, so the Controls, Interactions, and Events at least target the dedicated Controller Component only. However, MVC addresses no separation between the three aspects. It just does not prohibit the sep-aration of these three aspects. ■[REQ-F5] Dialog-Level Structuring: POOR: MVC does not motivate the structuring of the User Interface at the level of individual Dialogs. It just does not prohibit the use of the pattern at this level. ■[REQ-F6] Dialog Life-Cycle and States: POOR: MVC does not explicitly sup-port a flexible custom life-cycle of Dialogs, although it could be estab-lished around it. ■[REQ-C1] HTML5 Single-Page-Application Approach: VERY GOOD: MVC can be used just fine for HTML5 Single-Page-Applications as long as the View Component renders the View Mask into the Document Object Model (DOM) and can coordinate this rendering with both parent (named “superview” in MVC) and child instances of the MVC pattern. ■[REQ-C3] Potential Offline Operation: VERY GOOD: MVC holds all its information in the Model Component and is not directly tied to any corresponding Back-End communication. It is out-side the scope of MVC how the information is coming from the Back End to the Model Component. ■[REQ-C4] Near-Real-Time Updates: VERY GOOD: MVC holds all its information in the Model Component and can leverage the Observer pattern on those Model Components. Hence, it can potentially support near-real-time updates just fine. ■[REQ-A1] Separation of Model, View, and Control: PERFECT: MVC explicitly distinguishes between and separates Model, View and Control aspects of the User Interface. This is its primary contribution, of course. ■[REQ-A2] Distinguished Presentation Model: NOT AT ALL: MVC does not distinguish between a Presentation Model (see Subsection 5.2.1 on page 103) and the underlying Domain Model. MVC just has the single Model Component, and it is considered a Domain Model because it is usually pre-existing and especially attached to multiple View or Controller Com-ponents. ■[REQ-A3] Dialog Instantiation and Reusability: POOR: MVC just states that the View and Controller Components are instantiated, starting with the View Component. However, it is not stated by MVC whether the implemen-tation of those two Components has to allow or just can allow multiple in-stantiations and reusability. MVC at least does nothing explicitly to support multiple instantiations and reusability.MVC’s Model Component is a pre-existing Domain Model and not a Dialog-specific Presentation Model. This has many consequences, including no clear storage for non-domain information like User Interface states.Chapter 5: State of the Art76 ■[REQ-A4] Dialog-Level Component-Orientation: POOR: MVC does not ex-plicitly focus on the Dialog level. Hence with MVC one can use Dialog-level Component-Orientation by treating the View and Controller Components as a grouping Dialog Component. However, MVC at least does nothing to support or even motivate Component-Orientation at the Dialog level. ■[REQ-A5] Hierarchical Dialog Communication: VERY POOR: In MVC the View knows about the parent View (“superview”), and the Controller knows about “other” Controllers. This allows the creation of a hierarchy of MVC patterns and one could communicate along this hierarchy. However, MVC does not explicitly support or motivate such a hierarchical environment. ■[REQ-A6] Transitive Dialog Communication: NOT AT ALL: In MVC the View knows about the parent View (“superview”), and the Controller knows about “other” Controllers, but there is no notion of any transitive commu-nication between neither View nor Controller Components. ■[REQ-D2] Hierarchical Development-Time Dialog De-Composition: POOR: In MVC the View knows about the parent View (“superview”). However, MVC does not state how to de-compose a User Interface into this hierarchy of Views. ■[REQ-D3] Distributed Orchestration of Run-Time Dialog Re-Composition: VERY POOR: In MVC the View knows about the parent View (“superview”). However, MVC does not state how to re-compose a User Interface from this hierarchy of Views. Especially, it does nothing explicitly to support the distributed orchestration for the hierarchical re-composition of the User Interface during run time. ■[REQ-D4] Event-Driven Architecture: VERY GOOD: In MVC the Controller Component supports the direct mapping of user Dialog interactions onto corresponding programmatic events. ■[REQ-E1] Potential Web Technology Independence: PERFECT: MVC can be used perfectly in both Web and non-Web technology contexts as it is in no way tied to one of those contexts at all. ■[REQ-E4] Head-Less Run-Time Testing: VERY POOR: MVC does not really al-low the “head-less” (aka DOM-less or Browser-less) testing of the User In-terface during run time, because for this scenario the pattern has to be driven without any connection to the DOM. As in MVC the purpose of the Controller primarily is to drive the input devices, and the purpose of the View primarily is to drive the output device, “head-less” testing is not im-possible, but requires at least the full mocking of input and output devices. ■[REQ-E5] Massive Dialog Scalability: POOR: MVC can be used on a Dialog-level and then instantiated a hundred times for a complex User Interface. However, as MVC has no inherent notion of a hierarchy except for the “su-perview” aspect, MVC does nothing explicitly to support the massive scal-Model-View Separation Patterns77ing. For this, it would have to explicitly support the hierarchical composi-tion and communication.Pattern JudgementModel-View-Controller (MVC) is a highly influential pattern which especially contrib-uted the essential Model-View separation. The shortcomings of MVC are: ■No Hierarchy: MVC primarily targets the management of single User Inter-face (UI) Dialogs or Widgets and especially has no reasonable notion of the hierarchical nature of the UI as a whole. ■No Presentation Model: The MVC Model Components are Domain Models and not Presentation Models (see Subsection 5.2.1 on page 103), MVC has no clean location for storing non-domain information like UI parameters and UI states. Usually, that information is stored in the View Component of MVC. ■Separate Input/Output: The separate input and output handling were use-ful with the older Graphical User Interface (GUI) frameworks at the time of its invention, but with today’s GUI frameworks it is even an obstacle.5.1.2 Hierarchical Model-View-Controller (HMVC)Pattern OriginThe Hierarchical Model-View-Controller (HMVC) software architecture pattern was introduced in 2000 by [Cai et al. 2000a]. The authors later confirmed [Cai et al. 2000b], they originally were unaware of the older, very similar and more generic Presentation-Abstraction-Control (PAC) pattern (see Subsection 5.1.3 on page 83) and that they then considered HMVC to be a special variant and a subset of PAC.On the other hand, as HMVC is more closely reusing MVC (see Sub-section 5.1.1 on page 72) and only addressing the User Interface (UI) architecture. [Greer 2007] also stated on the difference between HMVC and PAC: “While its organization of MVC triads into a hierarchy is similar to PAC, it differs in that Model and View components maintain the same observer relationship as within MVC, and more notably that it seeks only to address the presentation layer of an application rather than addressing the entire applica-tion architecture.”In [Haft & Ollek 2007], the HMVC pattern was a major inspiration for the Qua-sar Client architecture, and here HMVC was extended by an enclosing framework which manages the life-cycle of the Dialog-realizing MVC Triads of HMVC. This ap-proach, in turn, was finally the major inspiration for the approach of the HUICA.HMVC heavily inspired Quasar Client and later the Hierarchical User In-terface Component Ar-chitecture (HUICA).Chapter 5: State of the Art78Although not directly the original HMVC pattern, but [Gallego-Carrillo et al. 2005] and [Gallego-Carrillo et al. 2006] motivates a similar hierarchical MVC usage, too. Pattern DescriptionFigure 5.3 on page 78 shows a summarizing illustration of the HMVC pattern. In HMVC there is a hierarchy of MVC Triads. The MVC Triads are linked together by par-ent and child references between the Controller Components of each MVC Triad.The MVC Triad of HMVC is very closely related to the MVC Triad of the traditional MVC pattern (see Subsection 5.1.1 on page 72), but with a few subtle differences: ■Controller-Driven: In MVC the Component Triad is instantiated at and driv-en by the View Component. In HMVC the Component Triad is instantiated at and driven by the Controller Component. ■Knowledge-Relationship: In MVC the Controller and View know both each other and the underlying Model, while the Model does not know about both the Controller and the View. In HMVC the Controller and View know ModelViewInput/OutputDevicesread/updaterendercontrolupdateXComponentKnowledgeRelationshipRun-TimeCallnotifychildcontroller*parentcontroller0..1updateControllerRun-TimeCall-BackFigure 5.3: Hierarchical Model-View-Controller (HMVC) PatternModel-View Separation Patterns79each other, the Controller knows the Model and the Model knows the View. This last point, that the Model knows the View but not vice versa, is the major difference to MVC. ■Local Model: In MVC the Model Components are pre-existing, can be con-sidered a global resource and are attached to by multiple Controller and View Components. In HMVC, the Model Components are directly belong-ing to the MVC Triad and have a life-cycle equal to the MVC Triad. This way the Model Component can be considered more like a Presentation Model than a Domain Model. ■Optional Controller: In MVC the Controller is mandatory, in HMVC it is op-tional. If it is left out in HMVC, the parent Controller has to take over the role of managing the View and Model. ■Combined Input/Output Device Handling: In MVC the Controller handles the input devices and the View handles the output devices. In HMVC the View handles both input and output devices and hence all code related to driving the User Interface rendering and event handling is located in the View only. ■View calls Controller: In MVC, as the input event handling is located at the Controller, the View does not directly have to call the Controller. In HMVC, as the input handling is also at the View and the View does not know the Model itself, the View is forced to handle input events by delegating them to the Controller (even if the Controller in turn usually just further dele-gates it to the Model). ■Model calls View: In MVC, the Model does not know the View and only indi-rectly calls the View via the callbacks of an Observer pattern on the Model. In HMVC, the Model knows the View and directly calls the View to update it in case of Model changes.Pattern EvaluationThe evaluation of the Hierarchical-Model-View-Controller (HMVC) software architec-ture pattern against the subset of our Requirements Suite (see Section 4.2 on page 61) one can find in Figure 5.4 on page 80. ■[REQ-F3] Separation of Mask, Style, and Behaviour: VERY GOOD: HMVC clearly distinguishes between View and Controller Components, so inher-ently separates at least the Mask and Style from the Behaviour. Whether Mask and Style are also separated is not addressed by HMVC, but at least not explicitly prohibited and hence also possible. ■[REQ-F4] Separation of Controls, Interactions, and Events: VERY POOR: HMVC, in contrast to MVC, no longer distinguishes between input and out-Next >