Menu
The HMVC architecture groups each MVC module into a triad and enables the communication between the controllers of each triad. In the above diagram, each MVC component or triad can communicate externally between the controllers of other MVC triads. Thus enabling a parent-child relationship between the modules.
Modular Extensions - HMVC Modules are groups of independent components, typically model, controller and view, arranged in an application modules sub-directory that can be dropped into other CodeIgniter applications. HMVC stands for Hierarchical Model View Controller.
HMVC is simply MVC but in the component-ordered base. Assume you have a website that has a blog and a forum part. HMVC divides these two parts into MVC components so you can have each of them separately developed but used as one!
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.
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
In Kohana, at least, an HMVC request is a HTTP request that is serviced "internally": instead of being issued over the network, it's routed, dispatched and handled by the framework itself. The similarity of the names "HMVC" and "MVC" is confusing in that it suggests an underlying connection between the terms that does not in fact exist: one is not a minor variant or modification of the other, they are completely different things. (HMVC is also described as Ajax without the client-side HTTP request.) Kohana's emphasis on, and support for "HMVC" means that the framework has strong support for a HTTP-based service oriented architecture.
The advantage of this architectural pattern is that since the same "calling convention" is used for internal and external requests, it's trivial to convert "internal" service requests to "external" requests or vice versa as the need arises.
Whilst this is a sensible architectural pattern, giving it its own name seems unnecessary (Symfony2 describes the same concept "sub-requests"), and in fact the name seems to be a misnomer: there's no particular requirement or need that the requests form a hierarchy (other than the standard call graph of every imperative program); the requests could easily be recursive, for example.
[Update Apr 2011, Mar 2012: Expanded on answer in response to comments.]
HMVC is Hierarchical Model View Controller.In in normal MVC every GUI object has its MVC.But there is no any relation between the parent GUI object and Child GUI object unlike HMVC. In HMVC each GUI object has access to its child objects and each of child object can access to its parent object.
So in every view there is a parent view.Through which it can access it parent view. For in every controller there is a parent controller through which It can pass the event to parent controller (If event is not in its scope.)
For details description please click here
New link is this address
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With