What is the HMVC pattern?

HMVC is closely related to the "component based" approach to dispatching. Basically, instead of having a single dispatcher, which delegates to a controller, each controller can act as a dispatcher it self. This gives you a hierarchy of controllers. The design is more flexible and causes better encapsulation of code, but at a price of higher abstraction. Konstrukt is designed around this pattern.

See also this answer: https://stackoverflow.com/questions/115629/simplest-php-routing-framework/120411#120411

Sam de Freyssinet (one of the Kohana developers) wrote a rather in-depth article about HMVC, what it is, and how it can be used.

Link is dead: New Link - https://web.archive.org/web/20160214073806/http://techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc/

I am currently in the process of developing my own PHP 5.3 HMVC framework called Alloy. Since I am heavily invested in and sold on HMVC, I thought I could offer a different view point, and perhaps a better explanation of why HMVC should be used and the benefits it brings.

The largest practical benefit of using an HMVC architecture is the "widgetization" of content structures. An example might be comments, ratings, Twitter or blog RSS feed displays, or the display of shopping cart contents for an e-commerce website. It is essentially a piece of content that needs to be displayed across multiple pages, and possibly even in different places, depending on the context of the main HTTP request.

Traditional MVC frameworks generally don't provide a direct answer for these types of content structures, so people generally end up duplicating and switching layouts, using custom helpers, creating their own widget structures or library files, or pulling in unrelated data from the main requested Controller to push through to the View and render in a partial. None of these are particularly good options, because the responsibility of rendering a particular piece of content or loading required data ends up leaking into multiple areas and getting duplicated in the places it is used.

HMVC, or specifically the ability to dispatch sub-requests to a Controller to handle these responsibilities is the obvious solution. If you think about what you're doing, it fits the Controller structure exactly. You need to load some data about comments, and display them in HTML format. So you send a request to the comments Controller with some params, it interacts with the Model, picks a View, and the View displays the content. The only difference is you want the comments displayed inline, below the blog article the user is viewing instead of a completely separate full comments page (though with an HMVC approach, you can actually serve both internal and external requests with the same controller and "kill two birds with one stone", as the saying goes). In this regard, HMVC is really just a natural byproduct of striving for increased code modularity, re-usability, and maintaining a better separation of concerns. THIS is the selling point of HMVC.

So while Sam de Freyssinet's TechPortal article on scaling out with HMVC is interesting to think about, it's not where 90%+ of the people who use HMVC frameworks are going to get real, practical, day-to-day benefits from it.