COMP 310	How To Make Mini-MVC's Inside a Main MVC

Large object-oriented systems consist of many components tied together using the Model-View-Controller Design Pattern.   But each one of those components is not only isolated and encapsulated, but may also be quite large; large enough to warrant being architected with MVC as well.   Thus a large system commonly consists of layers of MVC's.

Often times, a system grows dynamically, adding new sub-systems which have their own "mini-models" and "mini-views".    It is tempting, but incorrect to have the main, original model construct both the mini-model and its associated mini-view.  To do so would require knowledge of the view particulars by the model in violation of the basic MVC principles of decoupling.    So how to create the new mini models and views?

The key here is the entity that has always known about both the model and the view:  the Controller.   The controller always makes the adapters that bridge models and views, no matter where they come from.    Remember that the main adapters between the main (original) model and view were made by the controller and in such, the controller can create the code necessary to construct mini-models, mini-views and their mini-adapters.  

The factory method on the mode-to-view adapter creates a mini-controller that, as controllers always do, instantiates the mini-model, its associated mini-view and any mini-adapters that connect them.   This factory method then returns an adapter back to the main model that enables the main model to communicate to the entities inside of the mini-MVC, e.g. the mini-model, without requiring the main model to know anything about the internals of the mini-MVC.

Often, the mini-view is physically part of the main view, e.g. is a panel on a tabbed pane, so the mini-controller will need to install the mini-view into the main view.

The mini-model can't tell the difference between the main model and anything else in its view, so any communication from the mini-model to the main model is through the mini-model-to-view adapter.   The mini-controller, in conjunction with the main controller is perfectly capable of setting up this line of communications.

In the diagram below, follow the numbered steps to see how the system creates a new mini-MVC system by calling a factory method on the main model-to-view adapter.  That factory method creates the mini-controller which in turn, creates all the pieces of the mini-MVC including installing the mini-view into the main view if necessary.   The factory method returns an adapter back to main model that enables it to communicate with components of the mini-model but yet still be decoupled from them.   In the end, an imbedded MVC is created where all elements of the total system are capable of communicating with all other pieces but yet are still decoupled from one another.  Such is the power of delegation and encapsulation!

Note that the adapter(s) to/from the mini-view may actually be attached to any other module in the system as determined by the mini and main controllers.

No single way to do it!

There are many different ways in which one can think about the relationship between the main MVC and the mini-MVCs.   Remember that in the larger picture, all of this is really just about multiple decouple modules in a larger whole.  It is important to keep in mind that fundamentally, "models" and "views" are the same thing; these are just labels. The notion of a "mini-MVC" is really just a way of grouping some of those modules into a decouple sub-collection.

Here are two examples of how a mini-MVC might relate to a larger main MVC:

Note how the adapters to/from the mini-MVCs and the main MVCs are really no different than any other adapters!

In the left-hand example above, the mini-MVC is considered a completely separate, self-contained entity.   The mini-MVC's view only interacts with the mini-model and is completely decoupled from the main view.    The only interaction with the main system is through between the mini and main models.

In the right-hand example above, the mini-view is integrated into the main view and interacts directly with it.  The mini-view is a part of the main view and the mini-model is part of the main model.    Thus, the each include interactions with their outside worlds that include direct model-to-model and view-to-view type behaviors.  

Note that in either case, since no module every knows what is on the other side of an adapter, the modules in the mini and main MVCs above really have no operational idea which conceptual configuration they are in.   The difference above is really just for us humans to understand the system more easily.    The difference between adapters that go strictly between the mini-model and mini-view vs. the adapters that go to/from the main model and view is strictly one of being different semantic groupings of behaviors.  

© 2017 by Stephen Wong