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:

As I rolled out new applications and subsystems, it would have really helped to be able to encapsulate that functionality, both programatically and structurally.

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

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:

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.