Key takeaways
MVC has been one of the first software development principles exposed to every new generation of software developers. MVC shall be viewed as a general architectural principle and methodology. The semantics of MVC triad components varies by architectural contexts. HTTP-based web MVC (WMVC) can be classified into three distinctive categories, sWMVC, dWMVC, and pWMVC. Asynchronous and real time change-observing "event loop" can be fulfilled for WMVC applications with recent technological advancements. Introduction
The MVC (Model-View-Controller) was originally intended for a narrowly defined design and implementation in developing desktop graphical user interface (GUI) applications. Along with object oriented programming, this classic MVC has been one of the first software development principles exposed to every new generation of software developers. Although it has such a consequential influence in today's industry, it is also evident that its connotations have lost precision in an ever-increasingly interconnected computing age. This is especially so in the field of web graphical interface (WUI) development over the past 20 years. Therefore, the purposes of this paper are to present briefly the original MVC, and then delve into the evolution and variation of the web-based MVC.
Under the context of the WUI, the historical meaning and implications of the original MVC and its triad of objects have constantly evolved and morphed. So as to eliminate any confusion, WMVC will be used to describe the web-based MVC-esque architectural paradigms in this discussion. Major technological platforms continue to enhance their WMVC features, including ASP.NET MVC of Microsoft, Symfony of PHP, Django of Python, Merb of Ruby, and Java's JSR 371. These are largely driven by the role that JavaScript has played on the client browser and a number of new network protocols that enrich the client-server communications.
Since JavaScript was given a life saver in the form of XMLHttpRequest, it has become the darling of WUI developments. Over twenty JavaScript WMVC-based application frameworks have sprouted over the last few years, such as Dojo, Angular, Ember, Backbone, and React. Most, if not all, of these frameworks are focused on the client-side component interactions, particularly the view and controller members of the WMVC. Naturally, these renewed WUI developments once again have triggered substantial and sometimes passionate discussions related to MVC and/or WMVC. These discussions often focus on a specific aspect and/or under a specific context, resulting in a number of controller-focused variants of the (W)MVC, such as MVA, MVP, MVVM, Flux, Redux, and SAM. They are sometimes lumped together as MV* to indicate their variable emphases on the interactions between the view and the controller. The model component, which represents the real world of the view, has generally not been taken into consideration as a whole and/or has been regarded as a passive participant in the triangular relationship under the web application scheme.
Arguably, the model has experienced the most significant changes since the inception of the MVC almost forty years ago. For this discussion, the model is defined liberally to include the in-memory model object (such as record set), the source data/document/file/signal of system of record (SoR) behind the object, and all the processes synchronizing and bringing them together. The type of data repository of the model has evolved from a small floppy disk to RDBMS, and to MMDBMS (multi-model database management system). The repository has gone from co-locating with the in-memory model object isolated on the user's desktop to locating remotely from the domain object as broadband-connected, distributed and/or cloud-based systems. The data records in such externalized settings can be modified by multiple systems of an enterprise ecosystem and/or thousands of users of a consumer application. These different contexts have fundamentally altered the behavior of the model componen t, which in turn altered its communication and interaction with the other two partners of the MVC triad.
Original MVC
The original MVC (oMVC) was introduced in 1978 by a Norwegian computer scientist named Trygve Reenskaug, when he was working with the Smalltalk team at the renowned Xerox PARC research center. After its original formulation, the oMVC concept was first implemented as part of the Smalltalk-80 class library for creating desktop GUIs.
At the time, the desktop was far from a common household item and each was an isolated primitive machine. Machine storage was limited and self-contained. As shown in Figure 1, any manipulation to the oMVC model object is solely triggered through the controller by a user action. All three oMVC components communicate, synchronize, and remain stateful within a controlled environment. The primary role of the controller is to maintain the link between the user and the system (Figure 1). It arranges relevant GUI components and presents them to the user on the screen, which is a challenging task during the pre-Win95 time that MS-DOS is still a dominant operating system. Then, when the user takes actions, such as selecting a menu, entering inputs, and clicking a button, it translates these actions and send appropriate change messages to the model for processing.
Figure 1. A representation of the oMVC in a standalone desktop setting, showing a localized floppy disk data storage as part of the model. The controllers and the views are in pair relationship; but there are no communication of model changes between them. The controllers and views know about their model, but not vice versus.
Upon receiving the changes from the controller, the model does not update the related view(s) directly by invocation. In the model-view(s) relationship, each individual participant registers itself with the other for change notifications. When one changes, it raises an event, and the other takes appropriate actions in response. In Figure 1, the view is attached to and observes the model. As soon as the controller triggers an event to modify the model, the view must ensure that its appearance is updated as needed and reflects the state of the model accordingly. The view itself may also initiate notification signals to update the model. This observing (or subscribing) and notifying relationship between the model and the view helps to decouple them, thus multiple views can be attached to the same model to provide different presentations.
Notice, in Figure 1, that the controller does not directly modify the view. The view and the controller are often regarded as pairs of coupled objects in the Smalltalk community and in other subsequent desktop GUI application libraries. A view uses an instance of a specific controller type to implement an expected response. It can also strategically and dynamically switch the controller type under variable contexts to create desired behaviors. These view-controller pairs can be nested in a composite hierarchy (Figure 2A). The view-controller components in the hierarchy can interact and communicate between parent and children, and among their peers. Each of the individual view-controller child components in the hierarchy are most likely handling only a portion of the model object. Furthermore, from the composite perspective of the oMVC, the model can also be organized in a hierarchical manner so that all three members of the triad as a whole become hierarchical parent -child relationships as shown in Figure 2B.
(Click on the image to enlarge it)
Figure 2. Composite illustrations of the oMVC on the left and PAC (Presentation-Abstraction-Control) on the right.
Overall, the oMVC design paradigm is composed of a number of GoF design patterns, notably including Observer, Strategy, and Composite patterns. The architectural and schematic intents of the oMVC realm are maintained in the early desktop application libraries. The model component is composed of the application domain object and the localized/limited data storage. It plays a central role in the behaviors of the oMVC triad of classes by maintaining and broadcasting the state of the application domain. One of the key assumptions in the oMVC is that the model is stable. This is obviously a correct assumption within the desktop context of the 70s and 80s. However, in the WMVC realm, constant changes in the model are often the norm. The technological foundation required to broadcast the change to the user in real time (as the oMVC does) has only become available in recent years.
Classification of WMVC
Ironically, as desktop computers entered and popularized ordinary households in the 90s, especially in the era of post-Win95, traditional desktop applications fade into the background as internet-connected web applications started dominating the industry. Instead of being installed and executed on the computer of the end user like the desktop applications, web applications are hosted in a server located remotely from the user, creating a client-server relationship. In the remainder of this article, the terms browser and client are used interchangeably. Based on the location and execution of the WMVC triad objects in relation to the browser and the server, the WMVC is categorically grouped into:
Server-side WMVC (sWMVC) – All components of the WMVC are located and executed in the server. Dual WMVC (dWMVC) – The WMVC components are distributed between the browser and the server. Communication can initiate from either the client or the server side. Peer-to-Peer WMVC (pWMVC) – This is an architecture without a centralized server. All components of the WMVC are located in and executed from the client. And it can have its own sandboxed SoR. Server-Side WMVC (sWMVC)
With sWMVC, the user utilizes a browser as a thin client to access the application through a stateless request-response HTTP protocol (Figure 3). The client sends HTTP requests or inputs to the server, and then receives and displays a complete and updated web page (or other document). There are little interactions among the page components after the page loads; the page becomes static.
In the thin client-server paradigm of the sWMVC architecture, the application SoR repository is externalized to a centralized environment. It separates from the in-memory domain object within the application server. Both of the server and the data repository are remote from the the user's browser (Figure 3). The SoR storage often consists of one or more data sources such as relational databases. Since the data is externalized, it can be updated by out-of-band processes (or by different users). The data change flows only from the controller to the model (Figure 3); there are no inbound data change notifications to the application server when the data in the SoR is modified by different users or systems. Unlike the oMVC, there is no longer any direct association and mandatory synchronization between the model and its associated views. The view does not reflect the state of the model, which required the user to manually initialize a new HTTP request to synchronize and refresh the view. Therefore, the "s" in the sWMVC can also mean its static or stale nature of this type of WMVC paradigm.
Figure 3. A representation of the sWMVC paradigm, showing SoR externalized from in-memory domain object model (M) in the server. The controller no longer interfaces with the user like the oMVC; instead, it coordinates communications between the model and the view. The data change of the model flows one-way into the external data storage.
The model of the WMVC can be sketched as a layered architecture (Figure 4). The top layer of this architecture dictates the contract between the model and its related view-controller pairs. To fulfill the contract, a variable set of business logic and data access components may be involved in the processing stack. It serves as a link to all the information which is relevant to the view; the information can come directly from local SoR, from data clouds, or from other sources in the real world (such as sensors and data feeds).
Figure 4. A conceptual diagram of the WMVC model. It may consist of multiple architectural layers and variable data sources from locally and /or remotely accessible environments.
Differing from the oMVC, the relationship and communications among the triad objects shifted radically away from the original meanings and intents (Figure 3). Instead of acting between the user and the system of the oMVC (Figure 1), the controller of the sWMVC has taken on a higher-level coordinating role between the view and the model (Figure 3). Communication between the view and the model happens through the controller. The user interacts with the view, the controller contains the behavioral logic that links the model to their views, and is responsible for managing input, updating the model and producing appropriate output.
Although the architectural context of the web application is different from that of the desktop application, the introduction of the MVC into designing early web application frameworks essentially ignores its original schematics. Instead, the adoption takes in its fundamental idea that it is important to separate the three interacting object classes of variable responsibilities. This elevates the oMVC paradigm to a more generic level of architectural principle in UI design, so as to increase flexibility and maintainability of UI applications of any kind.
The sWMVC often involves multiple design patterns, including those used in the oMVC. For example, the role and behavior of controller may vary case by case and can include mediate, dispatch, and strategically delegate by state and template. However, in the oMVC, the observer pattern plays a key role in triggering communication between the three object classes, in particular when it is related to updating the view. The role of the observer diminishes in the sWMVC implementation. This results in the static and stale characteristics of the sWMVC. In recent years, interactive and rich web user experience has become possible as a result of several technological advancements.
Dual WMVC (dWMVC)
During the early days of the web age, there were consistent efforts to web-enable existing interactive desktop applications due to the ubiquity of the web browser. As a result of one of these efforts, a new web-based component which allows client-side scripts to issue asynchronous HTTP requests to the server was invented by Microsoft's Outlook web development. This led to the eventual creation and standardization of the revolutionary XMLHttpRequest (XHR) protocol at the turn of this century. Subsequently, it became the keystone of the Ajax technology.
Today, frameworks based on this technology allow the view-controller pair of the dWMVC (Figure 5) to be dynamically distributed and installed on the browser of the user desktop, mobile, and/or other devices. The asynchronous communications from these browser components to the model on the server are to synchronize the states of the triad objects of the dWMVC for selected or all view elements, and thus to provide the user up-to-date perceptions of the real world (model object). With this introduction, the XHR essentially fattens the client, bringing interactive user experience to the browser user.
XHR also triggered a movement of single-page application (SPA) development. Similar to an oMVC application, a SPA is a web site that stays on a single page to provide a seamless navigation experience. To the user, it does not appear to have any page reloading while going from page to page. The resources required to render the different pages are dynamically and asynchronously loaded, as needed, from the server behind the scene. The combination of the SPA and the interactive behaviors of the dWMVC application allows this paradigm to be classified as the latest entry in the rich internet architecture (RIA).
With the XHR protocol alone, the communication from the view-controller objects on the client to the model on the server side is still only a one way communication. In order to detect changes on the model, some kind of polling mechanism initiated from the view is still required. Polling is a resource intensive operation, which can become a performance concern. Ideally, like in the oMVC (Figure 1), any changes in the model should be published and broadcasted to all the related view-controller components in real-time. Figure 5 illustrates the two way asynchronous synchronization between the view and (through the controller) the model of the dWMVC architecture. This provides a foundation for a fully dynamic state synchronization among the dWMVC components based on a subscribing-publishing mechanism. Several recent advancements, including Server-Sent Events (SSE), WebSocket, and inbound database notification technology, have made this possible.
Figure 5. A dWMVC representation showing the triad objects distributed between client and server. Inbound change notification initiated from SoR can result in real time bidirectional update between the model and the view.
As part of HTML5, SSE is a mechanism that allows server-side components to asynchronously kick off and push data from a server component to the browser in real-time. With SSE, a client-side component initiates a request to establish a non-traditional HTTP connection with the server. Once the client-side component receives the initial response, it continues listening for subsequent responses from the server. Simultaneously, the server keeps the same initial client-server connection alive. Whenever new data becomes available, the server immediately pushes it out to the client through the same initial connection without the need for an additional request from the client. Therefore, SSE offers a solution for an asynchronous publish-subscribe event notification from the server to the client browser.
WebSocket is a communication protocol which can provide a full duplex connection between the browser and the server. When the client sends an initial request to the server, it uses a special HTTP header to inform the server that the HTTP connection may be upgraded to a full duplex TCP/IP WebSocket connection. Once a WebSocket connection is established, it can be used by both the browser and the server to send data to the other whenever it is needed.
With SSE and WebSocket communication protocols, the server can asynchronously deliver the in-memory changes of the model to the browser. However, as previously discussed, the model architecture can be layered across the server boundary to include external SoRs outside of the application server (Figure 4). The data records in the SoR can be modified by other applications or users. Whenever these out-of-band modifications occur, the SoR should have a change data capture (CDC) mechanism to detect and capture the changes, and then initiate and push the data changes inbound into the application server in real time, so as to have an end-to-end bidirectional publish-subscribe communication model (Figures 5 and 6). In Figure 6, at the center of the dWMVC wheel hub is the universe of the shared SoR/CDC data source(s). The bidirectional interactions between the data sources and the related in-memory domain model objects keep them in synchronization in real time. Each of the mini -dWMVC between the wheel spokes represents either individual business applications (of an integrated enterprise ecosystem) or individual users of an application.
Figure 6. A dWMVC Wheel representation, showing inbound change notification initiated from SoRs and resulting in real time bidirectional updates between the model and all the views (showing as mini-WMVCs).
The additions of XHR-Ajax, SSE, and WebSocket technologies to web-based architectural stacks, in conjunction with database inbound communication capability provided by database vendors, revitalizes the two-way interactive communications of the classic oMVC between the views and the model for the dWMVC. An increasing numbers of database vendors, including PostgreSQL and Oracle of traditional RMDB and RethinkDB and Cassandra of NoSQL, have implemented or planned to provide a mechanism of CDC and change inbound push notification to the application server.
Peer-to-Peer WMVC (pWMVC)
In the two WMVC architectural semantics discussed above, both are based on the client-server paradigm. The user's browser sends an HTTP request to retrieve content to the server, which replies with one or more response(s) containing the information requested. With this approach the server is responsible for storing and delivering all the contents and responds to all requests. This centralized approach can result in performance bottlenecks since the resources of the server infrastructure must be scaled and replicated appropriately to support all the potential request loads. Nowadays, this can become an issue due to the ever-increasing amount and the high frequency of real-time content delivery required, particularly during the periods with (unexpected) heavy traffic loads. Therefore, an optimum system is the one which can support high-quality end user experience in a decentralized manner, so that the user can acquire data in the shortest route and time. Peer-to-peer ( P2P) data exchange and communications allows end users to interact, retrieve and/or receive contents from other connected users, thus bypassing or reducing the load and potential bottleneck on a centralized server.
Traditional P2P systems require users to explicitly install proprietary desktop applications or plugins. Before WebRTC (Web Real-Time Communication) protocol is standardized and supported by web browsers, they did not have the capability to communicate to each other directly for P2P systems to operate. This standard is now supported by the majority of the browsers. WebRTC is an API definition which introduces supports for direct server-less browser-to-browser (browser P2P) data exchange and communication paradigm. WebRTC allows web browsers to open direct communication channels to other web browsers, introducing peer-to-peer solutions to the web application without requiring a centralized server environment to serve every web request-responses (Figures 7 and 8).
Figure 7. A pWMVC representation showing all the triad components located in and/or controlled by the client (browser).
With the pWMVC, all the triad components are located in and executed from the client and its related sandbox of the end user (Figure 7). The sandbox may include the user's local and/or cloud-based SoR storages which are accessible to the pWMVC application. In Figure 8, each of the mini-pWMVC between the wheel spokes represents an individual user browser environment. In comparison with Figure 6, the pWMVC wheel does not involve a centralized server and/or SoR infrastructure to facilitate ongoing web communication. The states of the mini-pWMVC components among the connected browsers remain synchronized by utilizing the WebRTC communication protocol.
Figure 8. A pWMVC Wheel representation, showing direct server-less P2P change notification initiated from individual user's browser and resulting in real time update to the views of all other peers. The M, herein, represents both the in-memory model object and the user's SoR.
Summary
The MVC by itself should be treated as a design principle or methodology, without any consideration of semantics. Its simple spirit is that a UI application of any kind can be broken down into three sets of interacting object classes. The behaviors of the triad of the object types should be examined under the contexts in which it is applied. In order to provide better understanding, proper naming annotations should be applied to actual design and implementation of frameworks and libraries for specific domains.
The WMVC is used to represent the unique schematics developed on the basis of the MVC methodology in the context of stateless HTTP-based domain. Three distinctive categories of the WMVC are identified as: sWMVC, dWMVC, and pWMVC. They are mechanically different from the oMVC, the original MVC. With the recent technological advancements, including standardized network protocols and proprietary inbound communication capability provided by specific database technologies, a MVC-esque change-observing "event loop" can be fulfilled for web-based applications. Therefore, fully interactive real-time rich WUI experience can be realized on behalf of modern browser users.
About the Author
Brent Chen has experienced in system architecture and application developments since the 90s. His solution deliveries have covered a range of subject domains, including payroll, human resources management,employee benefits management, regulatory compliance, health care, and governmental affairs. He has affiliated with a number of leading solution and service providers, such as Computer Sciences Corp, Northrop Grumman, and ADP, LLC. One of his research interests is exploring the fresh opportunities and emerging frontiers of current and developing web architecture and technologies.
Source:
Polymorphism of MVC-esque Web Architecture: Classification
