A few thoughts on HMVC web development

Hi ho,

You may have noticed that all of the popular PHP frameworks are using MVC.  However, change is in the air.  You may have noticed that more and more frameworks are supporting HMVC (modular) architecture.  Personally speaking, I think that this is a positive development and as far as I can tell, those web developers who have switched from MVC to HMCV have never looked back.  I am certainly a big fan of HMVC.

However, one of the challenges which the web development community has is how best to use HMVC.  In other words, we’re back to the tired old question, “What’s the best way to structure a website?”

Given the fact that the web development community still can’t quite agree on how basic MVC should work, I’m not optimistic about us having any standardised practices for HMVC any time soon.  Sure, we might be able to have some basic agreement on what model, view and controller means – but once you add Hierarchical to the equation then we seem to end up with a complete free for all.  I dare say that you would struggle to find any two developers who use HMVC in precisely the same way as each other.

In any event, I thought it might be helpful to throw down a few thoughts of my own.  These are just a few guidelines which I have come up with based on about 15 months of trial and error.  I confess to not following all of these rules myself (some of my older web app’s are a bit messy), however, I’m convinced that by following the guidelines below you’ll end up with a website structure which is easy to maintain and a delight to upgrade.

Here goes nothing:

TOP TIP 1:  Have a module for each and every database table

More Info:  Let’s imagine you were building a shopping cart application.  For developers using HMVC there is a massive temptation to have the major sections of the shop broken down into a handful of seemingly easy to manage modules.  For example, you might be tempted to have a module called ‘checkout’ which takes care of everything to do with the checkout process.

Now, your particular checkout process might potentially involve several tables interacting with each other.  Perhaps you have a MySQL table called ‘basket’ and another table called ‘orders’.  These would be tables which are related to the checkout process.

What I’m saying is that you should AVOID putting all of that stuff inside one module.  Instead you should create a module for each and every table.  In other words, you should have a module called ‘basket’ (which deals with the basket), another module called ‘orders’ (which deals with the orders) and so on.  Do that and you’ll end up with a website which is super easy to maintain and upgrade.

For ease of use, I recommend giving your modules the same names as the database tables that they are referencing.

TOP TIP 2:  Create the perfect model

More Info:  Most web developers use models to interact with database tables.  That’s fine.  Here an interesting thought for you – when you look at the logic, there’s only a handful of things that you can do with a database table.  This list includes things like:

  • add stuff
  • remove stuff
  • update stuff
  • count some rows
  • fetch some information
  • get the max ID
  • run a custom query of some sort (a table join or something like that)

So, with that being the case – why not just write one model which contains all that stuff?  Then, once you’ve got it working, forget it!

In my opinion – with only a few rare cases – the only thing that should change on a model is the name of the table(s) being referenced.  Now, I’m not going to bore you by pasting in my perfect model but I can tell you that at the top of the file the very first function says:

function get_table()  {
$table = “tablename”;
return $table;

All of the functions below that fetch the table name from the get_table() function.  The result?  I never have to waste a single minute messing around with models!  So, these days whenever I create a new model, I just copy my “perfect model” then change the name of the table being referenced at the top of the file.  How easy is that?

Top Tip 3:  Create the perfect controller

More Info: If you can create the perfect model and save tonnes of time, why not create the perfect controller too?  Once again, if you think about all the controllers that you’ve built, the chances are that they all do pretty much the sames things.  This list includes:

  • CRUD (creating, reading, updating and deleting)
  • Searching for stuff
  • Handling forms
  • and a few other bits and pieces

Unlike models, your controllers are likely to have custom features which make them unique.  I’m not denying that.  However, I’m just saying that we can reduce our workload and make life easier by making a sincere and intelligent attempt to create a ‘perfect controller’.  If we’re smart then our ‘perfect’ controller will be reusable.

Top Tip 4: Clarify the basics of MVC

More Info: I apologise if this seems a bit patronising but I think it’s a good idea to reminder ourselves of what M, V and C are intended for.  Our goal is to have nice clear separation between PHP code, database stuff and view files.  So, I recommend taking some time out to clarify precisely what those things mean and once you’ve clarified that information, stick to it like glue.

Whenever I’ve ran into problems building web applications, it’s usually turned out to be because somewhere along the line I have neglected the basics.  As far as I can tell, the same is true for other developers.  Get the basics right and you can’t go wrong!

Top Tip 5: Make EVERYTHING Modular! (well… almost everything)

More Info: Okay, here comes a disclaimer:

What I’m about to say is different from what lots of other people are saying.  There are tonnes of people who will disagree with what I’m about to say and that is fine.  It’s okay to disagree with me and it’s okay to assume that I’m a looney.  I probably am.  Here goes nothing:  

When you think about the various frameworks that are in use and you look back at all the different upgrades that we’ve had over the years then one thing becomes clear – stuff gets moved around.  I’m talking about folders.

If you are using any of the popular PHP frameworks then you can be sure that your framework is full of folders.  Here a folder, there a folder everywhere a folder!  Over the years I’ve saw folders come and go.  Folders for plugins, folders for libraries, folders for configuration files and – pretty much – folders for everything.

Now I wouldn’t for a minute recommend messing with the basic DNA of your framework and turning all your configuration files into HMVC modules.  That would be crazy.  However, when I see people using different directories for things like plugins and even templates – to me, it all seems a bit confusing.

So, when I design a new template for a website, I generally don’t do things the way other people do.  In my case, everything gets a module.  Can you guess what name I give the module that stores everything to do with the website template?  Yes Einstein – it’s called ‘template’.  Can you guess where that module lives?  The answer is, it lives happily alongside all the other modules.

To me that just seems more logical than the popular alternative, which is to have everything all over the place.

Top Tip 6: Enjoy freedom of views

More Info: Having babbled on about clarity of purpose with regards to models, views and controllers I think HMVC people can afford a little more freedom when it comes to view files.  Unlike MVC users, HMVC developers can enjoy the luxury of calling other modules from views.  This – of course – means that we can easily add widgets to web applications and best of all, it only requires a couple of very short lines of code.

So, now that you have that ability use it.  I see a lot of developers beating themselves up because they added a couple of lines of code to some view files.  With HMVC I think we can afford to chill out a little bit when it comes to view files.  It’s one of the nice things about using HMVC.

Anyway, thank you for reading.  I think I’m done.  I do hope that these tips will help you to make the most of HMVC.  I wish you every success and lots of happy apps in the future.

Thank you!




  1. This was the type of outline of the basics that I’ve been looking for. Thanks for writing such a detailed piece. Hopefully I can take what I’ve learned and actually add it to my projects to make them better.

  2. parkerandhobbes · · Reply

    Thank you.

    I do want to stress that there’s lots of developers who would disagree with what I’ve said.

    I’ve already received one email from a guy who I respect. He completely disagrees with the way I use HMVC. So, please remember that the above article is just one man’s opinion. People can take my advice or leave it. I’m no great authority on HMVC and I’m merely offering some tips which have helped me.

    Many thanks for your positive feedback.

    1. Did this individual outline what they do differently than what you suggest? If so, would you mind sharing them here?

      I (and I assume your other readers) would be interested in hearing alternative views/methods on the subject.


  3. parkerandhobbes · · Reply

    Not yet. However, he has offered to meet me on Teamviewer to go over some of his ideas. If I ever get that information (and it turns out that there’s a better way) then I’ll be glad to come back and post it here.

    In the meantime, I’m satisfied with my method. It has helped me to build sites quickly and it has made upgrades dead easy.

    If there is a better method or if I’ve got things wrong then I’d encourage anyone to leave a comment and enlighten us all.

  4. Matthew Schenker · · Reply

    Thanks for another great article! Your blog has become one of my regular places to visit.

    Just curious, which framework are you using most these days and/or which framework do you think does the best with HMVC?

    For example, I’m mostly using CodeIgniter, and I know there are some very active discussions about HMVC with that framework.

    Thanks again!

  5. parkerandhobbes · · Reply

    Thank you so much. I’m grateful to you.

    I use Codeigniter too.

    In terms of which framework handles HMVC the best, I’m not really qualified to say. As far as I can tell though, Codeigniter code is easier to read than the other major frameworks. It’s just a shame that HMVC is an addon and not a part of the core framework.

  6. Wonderfull article. I’m currently in the process of taking my big mess of scripts i’ve been building up and trying to build my own HMVC for various reasons. Apparently it’s kinda what i’ve been aiming towards all along and just didn’t realise it.

    Much of what you talk about here are practices which i somehow automatically settled into, particularly when it comes to the Model and database interaction. It’s always very gratifying to see that something you’ve come about doing all on your own, fumbling around in your own little learning process is also supported by others with greater experience.

  7. Just a few questions regarding your post.

    For Tip 1:

    Aren’t the modules suppose to be the pages (every module has a controller which the function inside it are the pages)? I mean, if you want a checkout page, how would one do that if the module is separated by basket and orders?

    Do you mean modules = database tables?

    For Tip 2:

    For your perfect model, you can change the table name with the function but how about the fields?

    For Tip 3:

    Can you give just a simple example of a perfect controller?

    1. parkerandhobbes · · Reply


      1. You can associate the modules with anything you want. You could associate them with particular pages or general features or anything. In the past I used to use generic modules. So I’d have one module for uploading thumbnails for example. However, having played around with different ways of doing things my declaration is that associating modules with tables is the way to go. It’s easier to understand and your site won’t fall apart when you add lots of new features.

      For an online shop I would use three tables and therefore three modules:

    2. On table for adding items to the basket
    3. A second table for storing the main order details (customer id, ip_address, date of order etc)
    4. A table for tracking the items which have been purchased. This would be tied into the main orders table.
    5. Note: That third table would be virtually identical to the first table. The only real difference is that it would have an order_id column and it would represent ONLY items which have been bought and paid for. So, when somebody successfully buys, you’d have the shop automatically transfer from table one (the basket table) to table three (the order items basket).

      2. The fields are, for the most part, irrelevant because the active record commands don’t require the field names to work. Of course, my “perfect model” is just a starting point and you may need specific methods to deal with specific fields.

      3. Yes. Join the Insider Club at insiderclub.org. It’s free. Once you get on board then you’ll be able to go to http://www.davidconnelly.com/perfectcontroller where you can grab the code.

      Hope this helps.


  1. I’ll check the Insider Club. I think I’ll learn many from there. Thanks DC!

  • I want to create a Login Page. But my table name is accounts. Do I need to separate a login module and an accounts module? I’m having a problem on what to put in the login controller. Should I put the accounts model in the login controller? That will make the login module dependent on accounts module. Is it ok?

  • Leave a Reply to Jason Rogers Cancel reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out /  Change )

    Google photo

    You are commenting using your Google account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )

    Connecting to %s

    %d bloggers like this: