< PreviousChapter 5: State of the Art100the three aspects. It just does not prohibit the separation of these three aspects. ■[REQ-F5] Dialog-Level Structuring: ACCEPTABLE: MVVM, similar to MVC, does not explicitly 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. In practice, MVVM is used both at the Dialog and Widget level. ■[REQ-F6] Dialog Life-Cycle and States: POOR: MVVM, similar to MVC, does not explicitly support a flexible custom life-cycle of Dialogs, although it could be established around it. In practice, surrounding frameworks pro-vide such a Life-Cycle. ■[REQ-C1] HTML5 Single-Page-Application Approach: VERY GOOD: MVVM, 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 MVVM pattern. As in MVVM the View is often Figure 5.12: Evaluation Results of Model-View-ViewModel (MVVM) 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 APPLICABLEModel-View Separation Patterns101just a declarative HTML/XAML specification, and the embedding of MVVM instances happens via HTML/XAML tags, this coordination works just fine. ■[REQ-C3] Potential Offline Operation: VERY GOOD: MVVM holds all its infor-mation in the Model and ViewModel Components and is not directly tied to any corresponding Back-End communication. It is outside the scope of MVVM how the information is coming from the Back End to the Model Component. However, it is known that the ViewModel Component actively gathers its information from the underlying Model Component. ■[REQ-C4] Near-Real-Time Updates: VERY GOOD: MVVM holds all its infor-mation in the Model and ViewModel Components and can leverage the Observer pattern on the Model Components and definitely leverages the Observer pattern on the ViewModel Components. Hence it can potentially support near-real-time updates just fine. ■[REQ-A1] Separation of Model, View, and Control: GOOD: MVVM, similar to MVC, explicitly distinguishes between and separates Model (inside MVVM Model and ViewModel Components), View (inside MVVM View Compo-nents) and Control (inside ViewModel Components) aspects of the User Interface. Just the partial mixing of Model and some remaining Control as-pects in the MVVM ViewModel Component can be considered an unclean property. ■[REQ-A2] Distinguished Presentation Model: PERFECT: MVVM distinguish-es between a Presentation Model (the ViewModel Component) and the underlying Domain Model (the Model Component). Besides the usage of a data-binding mechanism, this clear separation is the primary contribution of MVVM. ■[REQ-A3] Dialog Instantiation and Reusability: GOOD: In MVVM the View and ViewModel Components are usually instantiated starting with the View Component, the ViewModel knows nothing about the View and the View is usually part of a hierarchy and knows at least its parent View. As a consequence, although not explicitly stated, MVVM has to support multi-ple instantiations and reusability. Moreover, all well-known implementa-tion frameworks of MVVM do this, too. ■[REQ-A4] Dialog-Level Component-Orientation: GOOD: MVVM supports Component-Orientation at the Dialog-level just fine by treating the View and ViewModel Components as a Dialog Component. ■[REQ-A5] Hierarchical Dialog Communication: ACCEPTABLE: In MVVM, sim-ilar to MVC, the View knows about the parent View (for embedding), and the ViewModel knows about the parent ViewModel (for data-binding). This allows the creation of a hierarchy of MVVM patterns and one could com-municate along this hierarchy. However, although all MVVM implementing Chapter 5: State of the Art102frameworks do, MVVM does not explicitly support or motivate such a hier-archical environment from a bare pattern perspective. ■[REQ-A6] Transitive Dialog Communication: ACCEPTABLE: In MVVM, similar to MVC, the View knows about the parent View, and the ViewModel knows about parent ViewModel, and there is at least transitive communication when hierarchically resolving information from ViewModel and its parent ViewModels. However, MVVM has no notion of an additional transitive Di-alog communication. ■[REQ-D2] Hierarchical Development-Time Dialog De-Composition: POOR: In MVVM, similar to MVC, the View knows about the parent View. However, MVVM does not state how to de-compose a User Interface into this hierar-chy of Views. ■[REQ-D3] Distributed Orchestration of Run-Time Dialog Re-Composition: POOR: In MVVM, similar to MVC, the View knows about the parent View. However, MVVM 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. Only the usual MVVM-implementing HTML/XAML-based frameworks allow the easy re-composition via simple tag em-bedding. ■[REQ-D4] Event-Driven Architecture: PERFECT: MVVM is inherently based on a bi-directional data-binding mechanism, and through this, it perfectly can support Event-Driven Architecture. ■[REQ-E1] Potential Web Technology Independence: PERFECT: MVVM, simi-lar to 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. It actually is used primarily in the context of native GUI frameworks. ■[REQ-E4] Head-Less Run-Time Testing: VERY POOR: In MVVM “head-less” testing is nearly impossible as all Component instantiation usually hap-pens through the View Components (“View First” approach). If it alterna-tively happens through the ViewModel Components, MVVM can support “head-less” testing, of course. ■[REQ-E5] Massive Dialog Scalability: GOOD: MVVM, 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 (because of the data-binding mecha-nism) usually always exists.Pattern JudgementThe MVVM pattern is the most modern variant of MVC, as it leverages a modern bi-directional Data Binding mechanism today’s User Interface frameworks usually provide.User Interface Utility Patterns1035.2 User Interface Utility PatternsGood software architecture advice is always worth considering, but it should never be always carried out. — Martin FowlerIn this section, some additional related Utility Patterns in the area of User Interfaces are presented. We intentionally do not evaluate them in detail against the require-ments suite (see section 4.2 on page 61) as their scope is very small. Hence, most-ly all requirements are not directly applicable. Nevertheless, these Utility Patterns are important to know for the Hierarchical User Interface Component Architecture (HUICA) (see Section 6.1 on page 115).5.2.1 Presentation Model (PM)The Presentation Model (PM) software architecture pattern was documented by [Fowler 2004a]. See Figure 5.13 on page 103 for an overview. In other contexts, it is also known under the name Application Model or View Model.In many Model-View-Separation patterns (see section 5.1 on page 71), most notably MVC (see sub-section 5.1.1 on page 72), MVA (see sub-section 5.1.4 on page 88) and MVP (see sub-section 5.1.5 on page 93), the Model Component is actually a so-called Domain Model. Those Model Components have a structure which, as good as possible, supports the direct abstract representation of the do-main of the application. However, the domain data in those Domain Models usu-Figure 5.13: Presentation Model (PM) PatternDomainModelread/updateupdatedupdatedXComponentRun-TimeCallRun-TimeCall-Backread/updateViewDataBindingPresentationModelChapter 5: State of the Art104ally cannot be directly mapped into the View Mask’s Widgets of the User Interface (UI). Instead, the domain data, usually, first has to be split or aggregated, and con-verted.For instance, the name of a person and its birth date might be stored in a Do-main Model as name: String; birth: Date, but in the UI, the name has to be split into forename and surname, and the birth has to be converted into a string representation. Once this information was edited in the View Mask, the forename and surname have to be merged into the name, and the string represen-tation of the birth date has to be converted into the Date object again.At last, when a bi-directional data-binding mechanism is used to bind a Model to a View Mask, these split, aggregation and conversion steps are no longer easily possible. As a consequence, the Model-View-Separation patterns (see section 5.1 on page 71) HMVC (see sub-sec-tion 5.1.2 on page 77), PAC (see sub-section 5.1.3 on page 83), and MVVM (see sub-section 5.1.6 on page 97) adopted the Presentation Model (PM) sub-pattern.The Presentation Model resides between the View Mask and the Domain Model. In contrast to the Domain Model, the Presentation Model has a structure, which, as good as possible, supports the direct abstract representation of the View Mask’s Widgets of the UI. This way one optionally can especially use a bi-directional data-binding mechanism between the View Mask and the Presentation Model.Furthermore, the Presentation Model also provides a clean location for storing the state of the UI, which is not existing on the Domain Model at all. The usual UI state consists of flags for disabling or hiding UI information, temporary error infor-mation, and many more. The result is a so-called Separated Presentation [Fowler 2006b] [Fowler 2006c].Additionally, the Presentation Model can be attached to multiple View Masks in parallel, and this way is the essential mechanism to show and synchronize multiple representations of the same data [Hatanaka & Hughes 1999].Finally, the Presentation Model can be explicitly considered an abstraction of the View Mask. As such, the User Interface program logic can be programmed against it, without even having to know about the particular optical occurrence of the View Mask. Moreover, the User Interface can be even generated [Barclay & Kennedy 2000] [Buck et al. 2013], perhaps even from a declarative model [Castells et al. 1997], and then just attached to the Presentation Model.5.2.2 Data Binding (DB)When using a Presentation Model (see sub-section 5.2.1 on page 103), there is nearly a one-to-one mapping between Presentation Model fields and Widgets in the View Mask of the View Component. Hence, the information can be automati-cally synchronized between them, in both directions. The result is known as the Data Binding pattern, usually achieved with Observer Synchronization [Fowler The distinction between Presentation Model and Business Model is one of the key to many modern User Interface approach-es.User Interface Utility Patterns1052004e], or at least Flow Synchronization [Fowler 2004g]. See Figure 5.14 on page 105 for an overview.Under the hood, the Data Binding usually uses the Observer pattern [Gamma et al. 1994] at both the Presentation Model and the View Mask’s Widgets to react on changes to the data at either side. During the data synchronization, the data usually can be optionally split, aggregated and converted.If the Data Binding is just replicating the data in one direction, the Data Binding is called uni-directional. If the Data Binding is synchroniz-ing the data in both directions, the Data Binding is called bi-directional.5.2.3 Negligible View (NV)All Model-View-Separation patterns (see section 5.1 on page 71) have a View Component. However, in MVC (see sub-section 5.1.1 on page 72), MVP (see sub-section 5.1.5 on page 93) and MVVM (see sub-section 5.1.6 on page 97) the View Component instantiates and drives the pattern. Hence, the View is not negli-gible and a fully mandatory part of the pattern during run time.The Data Binding pattern most prominently distin-guishes older and newer User Interface approach-es. It is key to reduce im-plementation overhead.XComponentRun-TimeCallModelupdatedread/updateViewRun-TimeCall-BackKnowledgeRelationshipDataBindingupdatedread/updateFigure 5.15: Negligible View (NV) PatternXComponentRun-TimeCallModelupdatedread/updateViewRun-TimeCall-BackKnowledgeRelationshipDataBindingupdatedread/updateFigure 5.14: Data Binding (DB) PatternChapter 5: State of the Art106This View-driven approach simplifies the hierarchical creation of the User Inter-face but complicates “head-less” testing of the User Interface. Furthermore, it does not support the separation between developers, who should focus on UI control-ling code, and graphic designers, who should focus on the visual UI design.The opposite is a negligible View Component which is even optional during run time. This is achieved by fully leveraging the Data Binding pattern and no long-er instantiating the UI with View Components.Unfortunately, this pattern has no separate name in the literature. However, we name this pattern Negligible View (NV). This pattern sometimes just is an aspect of the Passive View (PV) [Fowler 2006e] pattern. See Figure 5.15 on page 105 for an overview.Figure 5.16: Google Trends for the major products Google Angular, Facebook React and VueJS as of 2018-07Approaches in Practice1075.3 Approaches in PracticeUnderstanding a problem is knowing why it is hard to solve it, and why the most straightforward approaches won’t work. — Karl PopperBesides User Interface (UI) architecture patterns, in practice, there also exist various popular approaches for implementing UIs with the help of more extensive, “all-in-one” and usually also intrusive frameworks and smaller, Separation-of-Concern-based and usually also non-intrusive libraries.There is a myriad of existing frameworks and libraries for imple-menting UIs with Web technologies [Hannah 2018], but a few most rep-resentative ones are introduced here for reference. They are all, at least loosely, based on the idea of Component-Orientation. Most of them are inspired by the MVC or MVVM patterns and some are also inspired by the previous PureMVC approach [Hall 2008a] [Hall 2008b] [Hall 2008c] [Hall 2008d].For a quick overview of the “Interest over time” from Google Trends [Google 2006] for the three most trendy product Google Angular, Facebook React and VueJS, see Figure 5.16 on page 106.5.3.1 All-In-One FrameworksSencha ExtJSExtJS [Sencha 2007] was already developed by Sencha in 2007 and is one of the oldest commercial Web UI frameworks on the market today. As of this writing, it is available in its major version 6. It is accredited for its comprehensive functionality and its decent documentation. Its most distinct aspect indeed is its Java-Swing-inspired OOP-based program-ming model, where no HTML or CSS has to be programmed, and instead, OOP Com-ponent classes are instantiated and linked with each other, which then, in turn, render the HTML and CSS behind the scene. Instead of the traditional getter/setter-based Component configuration, a more modern JSON-based approach is used most of the time, too.ExtJS’s Model-View-Separation approach [Kumar 2012] was introduced very late in 2012-2014 with its major version 5 and hence ExtJS today optionally supports the MVVM pattern. Here, the (Business) Model is derived from the class Ext.data.Model, the View is derived from the class Ext.Component and Ext.app.ViewCon-troller and the View Model is derived from the class Ext.app.ViewModel. In Ex-tJS, the hierarchy-driving Components are the View Components. All major Frameworks and Libraries on the mar-ket come with their own distinct pros and cons for implementing User Inter-faces.Chapter 5: State of the Art108The most prominent drawbacks of ExtJS are the fact that its particular program-ming model is less popular in the Web technology community and that integrating third-party widgets into ExtJS is a rather complex task.EmberEmber [Katz et al. 2011] was created by Yehuda Katz in 2011 and is one of the oldest monolithic Open Source Web UI frameworks still present on the market.The most distinct aspect of Ember indeed is “all-one-one” approach, where Em-ber delivers all functionality at once, including dialog navigation, mask rendering, unit testing, and many more. Ember’s Model-View-Separation approach is based on the MVVM pattern. In Ember, the hierarchy-driving Components are the View Components. The Presen-tation Model is accessed through its model hook and is either based on plain JavaS-cript objects or models coming from the companion framework Ember Data.The most prominent drawbacks of Ember are its rather large code size, its steep learning curve, its non-native looking Handlebars-based View Mask templates and its more and more declining popularity [Hannah 2018].Google AngularAngular [Google 2010] was developed by Google in 2010 and is one of the most popular Open Source frameworks for Web UIs on the market today. During this doc-torate project, it went through multiple major re-designs and re-implementations, including the switch from JavaScript to TypeScript as the primary programming language and from OOP-inheritance to Java-annotation/decoration-style programming model for implementing Angular applications. Its most distinct aspect indeed is its embedding of the Data Binding mechanism into HTML. Its second distinct aspect is the use of Dependency Injection, an Object referencing mechanism popularized in the Java eco-systems. Angular’s Model-View-Separation approach is based on the MVC pattern where the View is based on the Angular HTML template language, and the Controller and Model are annotated/decorated TypeScript classes. In Angular, the hierarchy-driving Components are the View Components. The most prominent drawback of Angular is its required use of TypeScript, a language which is becoming more and more popular, but which is still considered somewhat esoteric in the Web community.AureliaAurelia [Eisenberg et al. 2014] was developed by Rob Eisenberg, a former Angular developer, in 2014, during the long transition of Angular from version 1 to 2.The most distinct aspect of Aurelia indeed is that it actively tries to align with the Web Component standards, supporting the HTML import mechanism, the <template> element, the Shadow DOM facility, and native HTML custom elements.As of 2018, the most pop-ular products for imple-menting User Interfaces with Web Technologies are Google Angular, Face-book React and VueJS.Approaches in Practice109Aurelia’s Model-View-Separation approach is loosely based on the MVC pattern where the View is based on the Aurelia HTML template language, and the Control-ler and Model are plain JavaScript classes. In Aurelia, the hierarchy-driving Compo-nents are the View Components. Although Aurelia is an appealing product feature-wise, the most prominent drawback of Aurelia is the fact that it has a noticeable smaller developer commu-nity than ExtJS and Angular.5.3.2 Separation-of-Concern-Based LibrariesFacebook ReactReact [Facebook 2013] was developed by Facebook in 2013 and is one of the most popular Open Source libraries for rendering UIs on the market today.Its most distinct aspects indeed are its use of JavaScript XML (JSX), for embed-ding the HTML template language directly into the JavaScript code, and the use of a Virtual DOM for avoiding unnecessary and costly updates to the DOM. As a conse-quence, React is a pragmatic and very fast UI approach.When it comes to Model-View-Separation, React actually can be considered to be just the View (and Controller) of MVC. React primarily is a View Mask rendering and Data Binding facility only.The most prominent drawback of React is the fact that JSX entirely breaks Separation of Concerns as it mixes the declarative View Mask spec-ification, the Data Binding specification and the programmatic control-ling of the UI.The React ecosystem also contains alternative implementations, like the ren-der-performance-optimized Inferno and the code-size-optimized Preact. They all provide a similar React API but optimize certain aspects. Additionally, the React ecosystem contains various solutions for implementing the underlying Presenta-tion Model. The most popular ones are Redux, Immutable and MobX.Google PolymerPolymer [Google 2015] was developed by Google in 2015 to leverage W3C’s forth-coming Web Components standard, the DOM-native solution for component-based User Interface development.Hence, its most distinct aspects indeed are its plain HTML look-and-feel through the Custom Elements feature and its powerful styling capabilities through the Shadow DOM mechanism. The most prominent drawback of Polymer is the fact that nearly all browsers still need so-called “polyfills” to emulate Web Components functionality.Facebook React is a very pragmatic approach for bare View Mask render-ing and Data Binding.Next >