PHP Database Class – Building an Abstract Database Class in PHP

abstract classArchitecturedatabasePHP

I wonder if I should write a database class for my application, and if so, how to accomplish it?

Over there on SO, a guy mentioned it should be written as an abstract class. However, I can't understand why this would be a benefit.

Do I understand correctly, that if I would write an abstract class, every other class that methods will need a database connection, could simply extend this abstract class and have its own database object? If so, how is this different from a "normal" class where I could instantiate an database object?

Another method would be to completely forget about my own class and to instantiate a mysqli object on demand.

What do you recommend?

Best Answer

Yes, you should use classes to access your database. A good link for further reading on that is to look up the Active Record Design Pattern and Object Relational Mapping

The benefit of this can be seen in the DRY Principle and the Law of Demeter question which was asked previously. By creating an abstract data access class, you keep the data access layer part of your application from leaking into your model/database entity classes AND you don't have to repeat yourself each time you have to make a new database model/entity.

Ok, so back to your question, so now, we build an abstract class to handle the CRUD for our database entities, so now, we only need to extend that abstract class and probably set some variables each time we add a new entity in the database. It makes the pain of writing SQL for your tables less annoying and much easier to handle by moving them all out to the abstract class as well as makes the data access layer of your application much manageable especially if you have a bazzillion models/database entities.

So whats the difference between making your abstract class and making a database model class then instantiating it with a database connection? Or the going straight to just using mysqli?

With the abstract class, you only need to code the data access layer of your application ONCE
Your code becomes DRY by eliminating the redundant database initializations
Better maintainability, you only need to change one part of your code to change how you access the database!
SQL Haters delight! They no longer need to directly touch SQL statements when dealing with ORMs

But as we are programmers, I would suggest not to rebuild this from scratch. No need to reinvent the wheel as they would say. There are already frameworks out there for PHP that handle ORM elegantly. You can look up popular MVC frameworks for PHP like Yii and Kohana.

Related Solutions

PHP – Dynamic Class Inheritance Techniques

It looks like you are having a design issue here: Tables should not extend the Database Abstraction Layer. Instead the DAL should be injected into the table as a dependency.

abstract class Table {
    protected $dal;

    public function __construct(DAL $dal) {
        $this->dal = $dal;
    }

    // whatever else all tables have in common
}

class Table_User extends Table {
    public function someMethod() {
        $this->dal->someOtherMethod();
    }
}

$table = new MyTable($dal);
$table->someMethod();

That way you will create a DAL at some upper scope and pass it down. This will also allow you to use multiple different database engines at the same time.

Additionally you obviously should not create your tables directly in your controller but let a specialized class do that. For example you could use a factory:

class TableFactory {
    protected $dal;

    public function __construct(DAL $dal) {
        $this->dal = $dal;
    }

    public function createTable($name) {
        $className = 'Table_' . $name;
        return new $className($this->dal);
    }
}

That way you can create a table factory at some point with an injected DAL and pass that table factory around.

$table = $factory->createTable('User');

PHP Database Design – Should Database Connections Be Closed After Use?

For the purpose of safe coding, you should always close database connections explicitly to make sure that the code was able to close itself gracefully and to prevent any other objects from reusing the same connection after you are done with it.

Using unset is the same as leaving the database connection open, as you're relying on the garbage collector to clean up after the variable as opposed to asking the connection to gracefully close the connection after you're done with it. Though as mentioned by CodeCaster below, doing so is acceptable since the garbage collector makes sure that the connections are closed.

A useful example, lets say you're eating lunch at a cafeteria somewhere. After eating, you have two choice, throw your left overs in the trash then return the plate/tray to its rightful place(thats cleaning up after yourself). And the other is just leaving your mess on the table and wait for someone else(the garbage collector) to clean it up for you.

If you clean it up yourself, you're sure that your mess is cleaned up. But if you rely on the garbage collector, right before the garbage collector cleans up your mess, what if some weird stalker decides to use your used utensils to aid them in their nightly fantasies about you, then return them back to the cafeteria just in time for the garbage collector to clean up your mess. Stuff like that can happen.

EDIT: Corrected my mistake about garbage collectors.

Best Answer

Related Solutions

PHP – Dynamic Class Inheritance Techniques

PHP Database Design – Should Database Connections Be Closed After Use?

Related Topic