< PreviousChapter 5: State of the Art90Pattern EvaluationThe evaluation of the Model-View-Adapter (MVA) software architecture pattern against the subset of our Requirements Suite (see Section 4.2 on page 61) one can find in Figure 5.8 on page 90. ■[REQ-F3] Separation of Mask, Style, and Behaviour: VERY GOOD: MVA 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 MVA, but at least not ex-plicitly prohibited and hence also possible. ■[REQ-F4] Separation of Controls, Interactions, and Events: VERY POOR: MVA, in contrast to MVC, no longer distinguishes between input and output de-vice handling. Both are handled by the View Component, so the Controls, Interactions, and Events at least target the dedicated View Component only. However, MVA addresses no further separation between the three as-pects. It just does not prohibit the separation of these three aspects.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.8: Evaluation Results of Model-View-Adapter (MVA) PatternModel-View Separation Patterns91 ■[REQ-F5] Dialog-Level Structuring: POOR: MVA, similar to MVC, does not motivate the structuring of the User Interface at the level of individual Dia-logs. It just does not prohibit the use of the pattern at this level. ■[REQ-F6] Dialog Life-Cycle and States: POOR: MVA, similar to MVC, does not explicitly support a flexible custom life-cycle of Dialogs, although it could be established around it. ■[REQ-C1] HTML5 Single-Page-Application Approach: VERY GOOD: MVA, similar to 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 and child instances of the MVA pattern. ■[REQ-C3] Potential Offline Operation: VERY GOOD: MVA, similar to MVC, holds all its information in the Model Component and is not directly tied to any corresponding Back-End communication. It is outside the scope of MVA how the information is coming from the Back End to the Model Com-ponent. ■[REQ-C4] Near-Real-Time Updates: VERY GOOD: MVA, similar to 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: MVA, similar to MVC, explicitly distinguishes between and separates Model, View and Control aspects of the User Interface. ■[REQ-A2] Distinguished Presentation Model: NOT AT ALL: MVA, similar to MVC, does not distinguish between a Presentation Model and the underly-ing Domain Model. MVA just has the single Model Component, and it is considered a Domain Model because it is usually pre-existing and espe-cially attached to multiple Adapter Components. ■[REQ-A3] Dialog Instantiation and Reusability: POOR: MVA just states that the View and Model Components are instantiated starting with the Adapt-er Component. However, it is not stated by MVA whether the implementa-tion of those two Components has to allow or just can allow multiple in-stantiations and reusability. MVA at least does nothing explicitly to support multiple instantiations and reusability. ■[REQ-A4] Dialog-Level Component-Orientation: POOR: MVA does not ex-plicitly focus on the Dialog level. Hence with MVA, one can use Dialog-level Component-Orientation by treating the View, Model and Adapter Compo-nents as a grouping Dialog Component. However, MVA at least does noth-ing to support or even motivate Component-Orientation at the Dialog level.Chapter 5: State of the Art92 ■[REQ-A5] Hierarchical Dialog Communication: VERY POOR: In MVA, simi-lar to MVC, the View knows about the parent View (“superview”), and the Adapter knows about “other” Adapters. This allows the creation of a hier-archy of MVA patterns and one could communicate along this hierarchy. However, MVA does not explicitly support or motivate such a hierarchical environment. ■[REQ-A6] Transitive Dialog Communication: NOT AT ALL: In MVA, similar to MVC, the View knows about the parent View (“superview”), and the Adapt-er knows about “other” Adapters, but there is no notion of any transitive communication between neither View nor Adapter Components. ■[REQ-D2] Hierarchical Development-Time Dialog De-Composition: POOR: In MVA, similar to MVC, the View knows about the parent View (“super-view”). However, MVA 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 MVA, similar to MVC, the View knows about the parent View (“superview”). However, MVA does not state how to re-compose a User In-terface 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 MVA, similar to MVC, the Adapter Component supports the direct mapping of user Dialog in-teractions from the View Component onto corresponding programmatic events towards the Model Component and the mapping of updated Model Component information towards the View. This way it can support Event-Driven Architecture just fine. ■[REQ-E1] Potential Web Technology Independence: PERFECT: MVA, similar to MVC, can be used perfectly in both Web and non-Web technology con-texts as it is in no way tied to one of those contexts at all. It actually is used primarily in the context of native GUI frameworks. ■[REQ-E4] Head-Less Run-Time Testing: VERY GOOD: In MVA, in contrast to MVC, the entire connection to the input/output devices is at the View Com-ponents, and the entire User Interface structure is primarily handled by the Adapter Components. This would allow head-less testing, although MVA has no explicit support for it. ■[REQ-E5] Massive Dialog Scalability: POOR: MVA, similar to MVC, can be used on a Dialog-level and then instantiated a hundred times for a com-plex User Interface. However, as MVA has no inherent notion of a hierarchy except for the “superview” aspect, MVA does nothing explicitly to support the massive scaling. For this, it would have to explicitly support the hierar-chical composition and communication.Model-View Separation Patterns93Pattern JudgementModel-View-Adapter (MVA) is a variant of MVC with reasonable properties. Its main drawback, similar to MVC and in contrast to HMVC and PAC, is that it does not really support the hierarchical structuring at the Dialog-level out-of-the-box.5.1.5 Model-View-Presenter (MVP)Pattern OriginModel-View-Presenter (MVP) is a software architecture pattern that was first pub-lished in [Potel 1996] and originated from Taligent, a joint venture of IBM, Apple, and HP. It was later picked up and adapted by [Bower & McGlashan 2000] for use in their Dolphin Smalltalk. Microsoft also picked it up for use in their SharePoint plat-form. In [Fowler 2006d], [Greer 2007], [Zhang & Luo 2010], [Qureshi & Sabir 2013], [Syromiatnikov & Weyns 2014], [Syromiatnikov 2014], [Malar & Kala Rani 2015], and [Borini 2017] the MVP pattern and its variations were further discussed. As there are various variants of MVP, which are also significantly different, the MVP pattern, unfortunately, has no unambiguous definition. The situation is fur-(Domain)ModelPresenterInput/OutputDevicesother presentersuperview****read/updateread(/update)rendernotifyread/updateupdatedupdatedXComponentKnowledgeRelationshipRun-TimeCallRun-TimeCall-BackupdatedAppli-cationModelViewFigure 5.9: (Dolphin Smalltalk) Model-View-Presenter (MVP) PatternChapter 5: State of the Art94ther confused by the fact that the original Taligent MVP [Potel 1996] introduced new concepts like Interactors, Commands, and Selections to the pattern (in con-trast to MVC) while the Dolphin Smalltalk MVP [Bower & McGlashan 2000] variant simplified the MVP pattern, by eliminating those concepts, again. This way the later MVP variants like Dolphin Smalltalk MVP were surprisingly very close to the tradi-tional MVC again. We focus on this Dolphin Smalltalk MVP variant here, as it is one of the most popular variants.Pattern DescriptionFigure 5.9 on page 93 shows a summarizing illustration of the (Dolphin Smalltalk) MVP pattern. The MVP pattern is very close to the traditional MVC pattern (see Sub-section 5.1.1 on page 72), but with primarily two distinct differences: ■Combined Input/Output Handling: The input and output device han-dling is now combined and located at the View Component. This perfectly matches the Application Programming Interfaces (API) of modern Graphical User Interface (GUI) frameworks. ■Presenter Component & Application Model: the MVC Controller Compo-nent is replaced with a Presenter Component which has the special twist that it now incorporates an “Application Model” (aka Presentation Model). This way the Presenter is able to handle User Interface states and keep the Model Component (aka Domain Model) clean from them.Pattern EvaluationThe evaluation of the Model-View-Presenter (MVP) software architecture pattern against the subset of our Requirements Suite (see Section 4.2 on page 61) one can find in Figure 5.10 on page 95. ■[REQ-F3] Separation of Mask, Style, and Behaviour: VERY GOOD: MVP clear-ly distinguishes between View and Presenter Components, so inherently separates at least the Mask and Style from the Behaviour. Whether Mask and Style are also separated is not addressed by MVP, but at least not ex-plicitly prohibited and hence also possible. ■[REQ-F4] Separation of Controls, Interactions, and Events: VERY POOR: MVP, in contrast to MVC, no longer distinguishes between input and output de-vice handling. Both are handled by the View Component, so the Controls, Interactions, and Events at least target the dedicated View Component only. However, MVP addresses no further separation between the three as-pects. It just does not prohibit the separation of these three aspects. ■[REQ-F5] Dialog-Level Structuring: POOR: MVP, similar to MVC, does not motivate the structuring of the User Interface at the level of individual Dia-logs. It just does not prohibit the use of the pattern at this level.Model-View Separation Patterns95 ■[REQ-F6] Dialog Life-Cycle and States: POOR: MVP, similar to MVC, does not explicitly support a flexible custom life-cycle of Dialogs, although it could be established around it. ■[REQ-C1] HTML5 Single-Page-Application Approach: VERY GOOD: MVP, similar to 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 is able to coordinate this rendering with both par-ent and child instances of the MVP pattern. As the instantiation of the Com-ponents starts at the View Component in MVP, this is usually no problem. ■[REQ-C3] Potential Offline Operation: VERY GOOD: MVP holds all its infor-mation in the Model and Presenter Components and is not directly tied to any corresponding Back-End communication. It is outside the scope of MVP how the information is coming from the Back End to the Model and Presenter Components.Figure 5.10: Evaluation Results of Model-View-Presenter (MVP) Pattern0%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 APPLICABLEChapter 5: State of the Art96 ■[REQ-C4] Near-Real-Time Updates: VERY GOOD: MVP holds all its informa-tion in the Model and Presenter Components and can leverage the Ob-server pattern on Model Components. Hence it can potentially support near-real-time updates just fine. ■[REQ-A1] Separation of Model, View, and Control: PERFECT: MVP, similar to MVC, explicitly distinguishes between and separates Model (in both Pre-senter and Model Components), View (in View Component) and Control (in Presenter Component) aspects of the User Interface. ■[REQ-A2] Distinguished Presentation Model: VERY GOOD: MVP, in con-trast to MVC, does clearly distinguish between a Presentation Model (here named the Application Model in the Presenter Component) and the un-derlying Domain Model (in the Model Component). ■[REQ-A3] Dialog Instantiation and Reusability: POOR: MVP just states that the View and Presenter Components are instantiated, starting with the View Component. However, it is not stated by MVP whether the implemen-tation of those two Components has to allow or just can allow multiple in-stantiations and reusability. MVP at least does nothing explicitly to support multiple instantiations and reusability. ■[REQ-A4] Dialog-Level Component-Orientation: POOR: MVP does not ex-plicitly focus on the Dialog level. Hence with MVP one can use Dialog-level Component-Orientation by treating the View, Model and Presenter Com-ponents as a grouping Dialog Component. However, MVP at least does nothing to support or even motivate Component-Orientation at the Di-alog level. ■[REQ-A5] Hierarchical Dialog Communication: VERY POOR: In MVP, similar to MVC, the View knows about the parent View (“superview”), and the Pre-senter knows about “other” Presenters. This allows the creation of a hier-archy of MVP patterns and one could communicate along this hierarchy. However, MVP does not explicitly support or motivate such a hierarchical environment. ■[REQ-A6] Transitive Dialog Communication: NOT AT ALL: In MVP, similar to MVC, the View knows about the parent View (“superview”), and the Pre-senter knows about “other” Presenters, but there is no notion of any tran-sitive communication between neither View nor Presenter Components. ■[REQ-D2] Hierarchical Development-Time Dialog De-Composition: POOR: In MVP, similar to MVC, the View knows about the parent View (“super-view”). However, MVP 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 MVP, similar to MVC, the View knows about the parent View (“superview”). However, MVP does not state how to re-compose a User In-Model-View Separation Patterns97terface 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 MVP, similar to MVC, the Presenter Component supports the direct mapping of user Dialog in-teractions from the View Component onto corresponding programmatic events towards the Model Component and the Observer pattern at the Model Component to let both view and Presenter be immediately notified of changes to the Model. This way it can support Event-Driven Architecture just fine. ■[REQ-E1] Potential Web Technology Independence: PERFECT: MVP, similar to MVC, can be used perfectly in both Web and non-Web technology con-texts as it is in no way tied to one of those contexts at all. It actually is used primarily in the context of native GUI frameworks. ■[REQ-E4] Head-Less Run-Time Testing: VERY POOR: In MVP, the entire con-nection to the input/output devices is at the View Component, and the instantiation of the View and Presenter Components start at the View Com-ponent. This makes problems in case one wants to achieve “head-less” test-ing. ■[REQ-E5] Massive Dialog Scalability: GOOD: MVP, similar to MVC, can be used on a Dialog-level and then instantiated a hundred times for a com-plex User Interface. Massive Dialog Scalability usually requires a surround-ing framework, which in practice usually always exists.Pattern JudgementThe major problem of the MVP pattern is that it has no unambiguous definition, because of the many variants. Furthermore, as the later and most popular variant, the Dolphin Smalltalk MVP, is very close (again) to MVC, all the earlier MVP variants look like an unnecessary detour from today’s perspective. Nevertheless, MVP mod-ernized MVC with the bundling of input/output devices and the introduction of an Application/Presentation Model. 5.1.6 Model-View-View-Model (MVVM)Pattern OriginThe Model-View-ViewModel (MVVM) software architecture pattern was invented by Ken Cooper and Ted Peters at Microsoft, and its basic idea 2005 was introduced in [Gossman 2005]. MVVM was then further explained in [Likeness 2010], [Baillie et al. 2011], [Osmani 2012], [Smith 2013], [Syromiatnikov & Weyns 2014], [Syromiatnikov 2014], and [Jaeckle et al. 2015].Chapter 5: State of the Art98MVVM became popular as the fundamental pattern in Microsoft’s Windows Pres-entation Foundation (WPF) and Silverlight. Outside the Microsoft-scope, the MVVM pattern is sometimes also known under the alternative name “Model-View-Binder.”MVVM was motivated by the fact that the View Component should be crafted by a designer (rather than a developer) in a declarative manner (rather than an im-perative manner). The design of the View Component should be even done graphi-cally from within WYSIWYG tools. Hence, the state of the View Components had to be factored out into a separate Component: the ViewModel Component.Pattern DescriptionFigure 5.11 on page 98 shows a summarizing illustration of the MVVM pattern. The MVVM pattern is very close to the traditional MVC pattern (see Subsection 5.1.1 on page 72), but with primarily the following three distinct differences: ■Combined Input/Output Handling: The input and output device han-dling is now combined and located at the View Component. This perfectly matches the Application Programming Interfaces (API) of modern Graphical User Interface (GUI) frameworks. Figure 5.11: Model-View-ViewModel (MVVM) Pattern(Domain)ModelInput/OutputDevicessuperview**read/updaterendernotifyupdatedupdatedXComponentKnowledgeRelationshipRun-TimeCallRun-TimeCall-Backread/updateViewDataBinding*parent ViewModel0..1View-ModelModel-View Separation Patterns99 ■ViewModel Component & Presentation Model: The MVC Controller Com-ponent is replaced with a ViewModel Component which has the special twist that it actually is a Presentation Model and provides both properties and commands to the View Component. This way the ViewModel is able to handle User Interface states and keep the Model Component (aka Domain Model) clean from them. The name ViewModel “means ‘Model of a View,’ and can be thought of as an abstraction of the view, but it also provides a specialization of the Model that the View can use for data-binding.” [Goss-man 2005] ■Data Binding Mechanism: Between the View and the ViewModel there is not just an Observer mechanism, but usually a true bi-directional Data Binding mechanism, provided by a surrounding framework.According to [Likeness 2010], in MVVM “the view is active. As opposed to a passive view which has no knowledge of the model and is completely manipulated by a controller/presenter, the view in MVVM contains behaviors, events, and data-bind-ings that ultimately require knowledge of the underlying model and viewmodel. While these events and behaviors might be mapped to properties, method calls, and commands, the view is still responsible for handling its own events, and does not turn this completely over to the viewmodel. One thing to remember about the view is that it is not responsible for maintaining its state. Instead, it will synchronize this with the viewmodel.” The MVVM pattern can be driven by either the View Component (“View First”) or the ViewModel Component (“ViewModel First”) [Likeness 2010]. The most com-mon approach is “View First” where the Component Triad is started to be estab-lished with the View Component.Pattern EvaluationThe evaluation of the Model-View-ViewModel (MVVM) software architecture pattern against the subset of our Requirements Suite (see Section 4.2 on page 61) one can find in Figure 5.12 on page 100. ■[REQ-F3] Separation of Mask, Style, and Behaviour: VERY GOOD: MVVM clearly distinguishes between View and ViewModel 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 MVVM, but at least not explicitly prohibited and hence also possible. ■[REQ-F4] Separation of Controls, Interactions, and Events: VERY POOR: MVVM, in contrast to MVC, no longer distinguishes between input and output device handling. Both are handled by the View Component, so the Controls, Interactions, and Events at least target the dedicated View Com-ponent only. However, MVVM addresses no further separation between Next >