Case Study for MVCCE Design Pattern

In earlier posts, I published cheat sheet summaries of my MVCCE design pattern, which extends and refines the classic MVC design pattern. I present here an example of the use of that pattern.

For the web sites of the family of brands of a major retailer, I created a "widget" to handle site search requests that used several interactive animations and responsive behavior, including type-ahead suggestions gathered via AJAX interaction with backend servers.

This configurable standalone GUI widget was written in essentially raw JavaScript, and it used the MVCCE design pattern.

Below is the design diagram (click to expand)  that was the blueprint for that widget.

Click to Expand

Following the "single flow" of data from left to right,

1. User Actions (i.e. things a user wants to do, use cases, etc),
2. are invoked by the user causing DOM Input Events (by clicking or typing or moving cursor),
3. which are caught by Controllers,
4. which decide which Command to invoke, with which parameters to send,
5. which uses Model APIs to manipulate/update the widget's (and/or application's) state,
6. which causes Update Events to be sent to Views which are "Observing" those Models,
7. and those Views use the DOM APIs to manipulate/update the browser display.

This widget, at the "compound" level, did not happen to generate Output Events for other Controllers to subscribe to.

As can be seen, several models, views, controllers are "composite" containing sub-components.

While it is less obvious from the diagram, the AJAX interactions with the server-side, result in Input Events from the async replies to data requests (e.g. type-ahead suggestions), which update the Models, which in turn cause the Views to update themselves (including the loading of images that correspond with the type-ahead suggestions).

Cheat sheets for MVCCE, my refinement on MVC design pattern

Over many years of building GUIs in many different graphic/OS environments (in recent years building Rich Internet Apps via JavaScript/HTML/CSS), I have always used and advocated the Model-View-Controller design pattern.  Along the way, I have come up with some refinements which are relevant now because fat JavaScript webpage apps have made fat GUI app programming come full circle.  And unfortunately, I see the same hodgepodge of non-MVC code in JavaScript/HTML that I saw 20+ years ago with ObjectPascal/C/C++ on X-Windows/Mac/PCs.

The main differences between vanilla MVC (ala original SmallTalk design pattern) and MVCCE are:

1. Commands and Events are added to the list of first class citizens (along with Models, Views, Controllers)
2. Components are explicitly expected to often be Compound and/or Composite,
   but methods are still segregated into Model, View, Controller, Command, Event interfaces;
   They are separate components with separate interfaces, to cover the separate aspects of a widget. (e.g. the View that renders a particular piece of DOM is not combined with the Controller that listens to events from that same piece of DOM).
3. Controllers are very restricted, moving "business/app" logic into Commands,
   
   with controller logic limited to handling events in order to decide which Command to call, and which parameters to pass to it.
4. Commands mirror semantically-high-level User Actions rather than being low level event handlers

I reproduce the two diagrams below (click to expand) created for a client as "cheat sheets" for the pattern I call MVCCE (MVC + Commands and Events)

Click to Expand 

Click to Expand