Hierarchical MVC

Hierarchical MVC (HMVC) is also sometimes referred to as Presentation Abstraction Control (PAC), because the two ideas are very similar. The core idea behind HMVC is to create fully self-contained Model-View-Controller triad structures so that each triad structure can be used and displayed independently of other triad structures. These triads are typically "pulled" in and displayed in the View (Presentation) layer with internal sub-requests to the necessary Controller. This design leads to more loosely coupled application parts (the controllers, models, and views that you build), and tends to be more user-interface focused, because HMVC lends itself to widget-type structures that can be called from the view, right where they need to be displayed. This is different than traditional MVC, where only one Controller is ever executed, and the widget and sidebar content is typically left up to a combination of layouts and view partials that get their data either by making direct read-only calls to Models or get data "pushed" to them from the requested Controller.

If you are having a hard time visualizing this concept, it may be helpful to think of an HMVC sub-request as a sort of server-side AJAX call to display a widget or certain piece of content where you make the call.

Hierarchical MVC in Alloy

In Alloy, the individual MVC triad structures that make up the whole HMVC system are referred to as modules. Modules typically consist of a Controller, a Model, and a handful of Views, but can be as simple as a single Controller that returns direct string content or any other response type. Modules can be rendered with an internal sub-request anywhere within your application (using the Kernel), but it is highly recommended that these sub-requests be made within the View layer.

Hierarchical MVC in Practice

In practice, Hierarchical MVC (HMVC) is most useful for applications and websites that require re-useable widget structures that will be used across multiple pages or accessed in many different ways. Consider the following example of a typical "event detail" page: 

Using Hierarchical MVC, each widget structure is an internal sub-request to another controller (traditionally called an MVC "triad"). There are no additional widget or component structures that have to be created, and the required functionality can be fully self-contained within its own Alloy module instead of loading the widget or sidebar data in an unrelated controller and pushing it out to the view like most other MVC frameworks require you to do.

Hierarchical Dispatches in Code

The image example provided above helps to illustrate all the different things that are possible with the Hierarchical MVC structure in Alloy. Below is the code for each corresponding sub-request - essentially the equivalent of saying "render this module right here, running this action, with these parameters"


            

              # 2. Event Reviews (nested dispatch) # dispatch is a raw, direct internal request. No modifications are made. echo $kernel->dispatch('Reviews', 'listForType', array('event', $event->id)); # 3. Map (nested view partial) # Returns new view template object; echo converts it to string and renders it echo $view->partial('_map', array('venue' => $event->venue)); #4. Event Recommentations (nested dispatchRequest) # dispatchRequest re-uses current Request object just like direct web request # Will resolve this as 'indexAction($request)' echo $kernel->dispatchRequest('Events_Recommended', 'index'); #5. Food Nearby (nested dispatchRequest w/params) # Will resolve this as 'indexAction($request, $lat, $lon)' echo $kernel->dispatchRequest('Restaurants_Nearby', 'index', array($event->lat, $event->lon));
            

            

          

        

      

      
      

    

  

  

Related Links