Text 4 Oct 28 notes Against HMVC

Meh, wrong title but after weeks without ranting I wanted to boost this up a bit. :)

Well, I had the occasion to talk with a colleague of mine about taming a CI application that was heading straight to chaos, reorganizing folder structures and such. Omissis suggested me to drop some HMVC in and I felt the usual shiver up my spine.

Something scares the crap out of me when it comes to rely on HMVC (or PAC). It’s just a gut feeling around useless overcomplexity, but I always dodged that approach while I was a lone wolf. Since this time the choice was not just mine, I asked myself why I was to averse to HMVC and I came up with conclusions that I think are worth sharing.

All is easier to understand knowing that, first of all, I’ve been (and I am, somehow) a happy drupalista. Actually, two years ago my bills was paid almost 100% building Drupal sites. What I love in Drupal is its framework-like structure, that makes inbuilt CMS’ limitations milder. If you ever tried to develop themes or modules for Drupal you know what I mean. You could customize almost everything.
What is often too much of a burden is to achieve a completely customized UX and workflow (ok, we got Rules and it’s awesome, but bear with me). That’s not much of a problem: after all you rely on a CMS to manage contents, so resulting sites often have contents, not user interaction, in their sights.

When I’m hired for custom solutions with a tailored UX (especially when someone else takes care of it and I’m the mere developer) I drop Drupal and grab a full-fledged framework.
Since they provide just the building blocks of a web application, a conventional structure for your code and often also a convention-driven codebase, you have to build the workflow from the start and despite there is more work required, nothing kicks in the way, so you don’t have to battle with predefined behaviors.

Well, I see HMVC as a very nice way to get the worse of both worlds! Using bundled models, controllers and views in a single distributed package, you’ll still have to code your app by yourself, but you also get some (perhaps) unwanted assumption on how it will be presented to your users.
Actually you could argue that it also has strengths of both, but this point of view doesn’t allow me to rant, so it’s useless in this context. :D

Seriously, how many times you stumbled in a framework module that was… argh… nearly perfect (if not for…). Editing it? Why not! Let’s take a look at this view… mh, I think you’ll have to change controller also since the workflow is a little different. Phew, this model must be rewritten a bit to make it sticky to desired workflow and… oh, shit! Hours passed and all you have is a crappy mess!

Suddenly you’re dreaming of good old helper classes, uh?!

I never bother with realizing this, but I now know what that gut feeling was about. Actually, even if contributed drop-in framework modules is not what I consider the right way to go, HMVC is a great tool to organize your very own code, improve maintainability and tidiness. Symfony (both 1 and 2) does a great job with code organization, for example. Still, I like simplicity and taking a closer look at CodeIgniter (we’re using it after all, and I think embracing the ground philosophy of a framework you could shirk some crap) I think that’s the real motivation that drove switching from modules to packages. This is not a plus per se, it just confirms how much CI fits my mindset, nothing else.

Any case now that I know my enemy, it doesn’t scares me, no more.
Happy hierarchy everybody! :)

  1. arantaweek posted this

This blog design is based on Munich theme by Prashanth Kamalakanthan. Powered by Tumblr.