Hierarchical Model-View-Controller (HMVC): Planning for the Future

The Problem with MVC

The Model-View-Controller (MVC) architectural pattern is a great start to making your websites and web applications more sophisticated. However, there are limitations.

As a professional web developer that uses the CodeIgniter framework (strictly MVC), I have had extensive, first-hand experience with MVC. At first, I thought it was great. It was so intuitive and well organized. The libraries and helpers were excellent. However, as one of my sites grew and evolved into the behemoth that it is today, it became apparent that MVC was not cutting it. As the number of files being developed grew from tens to hundreds to thousands, the ability to make systematic changes became increasingly complex.

Two problems had become apparent:

  1. As I rolled out new applications and subsystems, it would have really helped to be able to encapsulate that functionality, both programatically and structurally.
  2. On several occasions I found myself wanting to call a function in one controller from another controller.

 

So through some research, I realized that I was not the only developer out there who found the MVC architecture limiting. In fact, there was a solution to this problem: HMVC.

Hierarchical Model-View-Controller (HMVC) Architectural Pattern

As discussed previously in my post MVC FOR PHP: WHAT IS MVC AND HOW DOES IT APPLY TO THE WEB?, the MVC architectural pattern relies on the “triad” of components depicted below:

HMVC still uses this triad, but instead of limiting the developer to this single MVC environment where all controllers are in the same ./controllers/ base path, all models are in the same ./models/ base path, and all views are in the same ./views/ base path, HMVC allows developers to designate separate “modules” to house their own models, views, and controllers directories inside their own unique paths. For example, with HMVC a developer is not limited to:

./controllers/
./models/
./views/

But instead, the developer now has the option to do something like this:

./controllers/
./models/
./views/
./modules/module_1/controllers/
./modules/module_1/models/
./modules/module_1/views/
./modules/module_2/controllers/
./modules/module_2/models/
./modules/module_2/views/

And so on. So the HMVC can be diagram actually consists of several MVC triads relating like so:

Benefits of HMVC

The following are the main benefits of implementing an HMVC architecture:

  • Modularity: HMVC makes it easier to interchange chunks of code through encapsulation of functionality.
  • Organization: HMVC allows each module to contain its own models, views, and controllers directories, keeping related files contained.
  • Extensibility: By promoting modularity, HMVC allows systems to be more easily extended by simply adding or replacing modules.
  • Reusability: Since modules can call each other, HMVC allows for code to be easily reused.

 

References

 

facebooktwittergoogle_plusredditpinterestlinkedinmail

3 Thoughts on “Hierarchical Model-View-Controller (HMVC): Planning for the Future

  1. Pingback: Setting up HMVC in CodeIgniter 2.1 | Something::static();

  2. Glad to read this. I’m still having a little trouble envisioning the where/why/how, but since the concept is a new one, I’m rather curious.

    After re-reading this, it seems we are encapsulating entire MVC file structures are modules?

    • HMVC does two things. It separates the physical file structure and logic of the code, and it allows for reusability by allowing external files to call on the module’s controller directly (via a function call rather than a straight URL call only).

      So let’s say that you want to build a widget that you will embed on the homepage of a site, but you also want the same widget on embedded on another page on the site. This widget requires a Model, View, and Controller. With the limitations of MVC you will have to create two controllers with the same logic to accommodation this for the two differing pages. With HMVC these two controllers external controllers will be able call the widget’s own controller. This means you only have to create the widget’s controller functionality in one place.

      Hope that helps.

Post Navigation