Whilst I have good experience with OOP, I'm fairly new to the concept of (H)MVC. I understand the basic concept of modular design that comes with HMVC, it's the great attraction of it. But one thing that has been bugging me, and will hopefully help me understand HMVC better is how do you handle the database connection?

I would assume that you would have a module, lets call it Database, that would initiate the connection. Now at the start of my script I would have something along the lines of:

$dbConn = new Database();

That would initiate the connection to the database. However, when I want to run a query I need to run something along the lines of:

$query = "my query string";
$result = $dbConn->query($query);

So I need to access the query function of the database object. Now as far as I can tell in HMVC I shouldn't directly access $dbConn from within a model of another module. But almost every module will need to access $dbConn.

From my understanding this means that in the controller of all other modules, any time I need to run a query I would have to create a new instance of the Database module, passing in an array of arguments, telling Database which method to run and what arguments that method needs.

But then what if I need to make a call to the database half way through a method in a module's model? Quite often I will need to update a table, or select some data based on an if statement. Surely I shouldn't be moving that logic to the controller?

So that means I need to be able to access another module from within a model, which seems to break the rules of HMVC. So how do I implement a database module as this is confusing me?

2 Answers 2


HMVC is about UI composition, it has nothing to do with how the underlying layers communicate with each other. I'll expand a little on the example presented here.

Let's assume you want to have a view that enables a user to make a comment to a blog post. You would have fields for name, e-mail, title and comment, but you also want to have a field country displayed as a dropdown. In the action that displays this view you would make a database query that loads the countries and then populate that dropdown. Which is ok, but it forces you to duplicate the query and the view required to display the countries if you need it in another part of your application. A better approach would be to create separate controller for countries with an action that returns a view with the dropdown and then render that action whenever you need to show a list of countries.

This is the "widgetization" that the above article is talking about.

  • I fully understand that, what I don't get is how you run the query. To get the list of countries you send a request to the countries controller, which in turn contacts its model for a list of countries. Now how does the model access the dbConn? Does it do it directly or should it create the query and send that to the dbConn controller via its controller?
    – Styphon
    Feb 4, 2014 at 17:24
  • 1
    Think of MVC as a layered cake: views are the topmost layer, then comes controller, model and data access (dbConn). Each layer depends on the layers under it (preferably on the layer directly under it), never on those above it. With this in mind, only the model is supposed to know about dbConn and the query that needs to be run through it. dbConn does not need its own controller since it would make no sense. in other words: yes, the model creates the query and uses dbConn to pass it to the database.
    – devnull
    Feb 4, 2014 at 18:05

It's pretty much impossible to be truly 100% modular, there will always be certain dependencies. The best thing you can do is try to organize it in a way that makes sense to your particular project.

That said, it isn't forbidden to make Models from module A to communicate with models from module B.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.