How Do I Handle The Multiple Database Connects And Requests With Mvc?

[DeX]

I just started a MVC style web application and I have a model which has a sole job of creating a connection to the database. I also have more models which connect to various tables to do various jobs but they're separate files in the model class. How do I use the connection in the database_connection_model in all the other model classes? Do I pass it into every model I use from the controller or is there some other way? I've considered just connecting in the model constructor but then where do I close the connection? Please help. Thanks.

[gristoi]

you could use inheritance and have a base db model that all other models extend off

[akphidelt2007]

If I get you correctly, you aren't talking about connecting to different databases but using the same connection multiple times throughout the application?

 

I would look in to building a static db class.

[DeX]

If I get you correctly, you aren't talking about connecting to different databases but using the same connection multiple times throughout the application?I would look in to building a static db class.

Same database but multiple models which connect to various tables in that database. I could either:

a) connect to the database inside each separate model.

b) connect to the database in the controller and pass the returned connection into each model used

c) extend the database_connect model in every other model which uses it (I couldn't figure this out)Which is best?

Edited October 31, 2012 by DeX

[KevinM1]

Dependency injection is the right answer. The others don't make sense logically (extending your db class) or methodologically (static class).

[DeX]

Dependency injection is the right answer. The others don't make sense logically (extending your db class) or methodologically (static class).

So according to this website: [http://www.potstuck.com/2009/01/08/php-dependency-injection/], does that mean I would need a database setter method in every new model file I make and also a databaseConfig setter? That seems like a lot of unnecessary and redundant code.

[gizmola]

What KevinM1 was suggesting is that you pass your dependency (A database connection object) into the table specific models. Since those classes won't work without the database connection, it probably makes sense to pass it as a constructor parameter:

 

$foomodel = new FooModel($db);

 

Now one way to make this work well is to bake in a registry object into your controller class, where you will be making models. Or you could make it part of the controller class, perhaps as a base class, so that it is automatically something you can get access to in any controller, ala:

 

// In controller
$fooModel = new FooModel($this->getDb());

 

Let's say that all your controllers implement a base controller class -- then you simply have your getDB() check to see if it has a database connection object stored, or if not, creates a new one.

[DeX]

What KevinM1 was suggesting is that you pass your dependency (A database connection object) into the table specific models. Since those classes won't work without the database connection, it probably makes sense to pass it as a constructor parameter:

 

$foomodel = new FooModel($db);

 

Now one way to make this work well is to bake in a registry object into your controller class, where you will be making models. Or you could make it part of the controller class, perhaps as a base class, so that it is automatically something you can get access to in any controller, ala:

 

// In controller
$fooModel = new FooModel($this->getDb());

 

Let's say that all your controllers implement a base controller class -- then you simply have your getDB() check to see if it has a database connection object stored, or if not, creates a new one.

 

Okay, so this would be option B from what I posted earlier?