在PHP中选择设计模式？

Question

I develop web applications with PHP. I have many classes using a database connection.

This is the structure i generally use;

class SomeClass {
    private $db;

    function __construct(mysqli $db) {
        $this->db = $db;
    }

    function SomeFunction() {
        $this->db->query(...);
    }
}

And this is what i thought to use;

class Common {
    public static DB = new mysqli(...);
}

class SomeClass {
    function SomeFunction() {
        Common::DB->query(...);
    }
}

There are two parts of my question;

1. Which one is better practice? If i use first one, i have to pass database object to every class uses db. If i use second one, every class uses db will be dependent to Common class.

2. I made examples simpler. Actually i have a Database class extends mysqli and a DatabaseTableManager class using Database class. I add GetTable() function to Database class. I create DatabaseTableManager objects in this function (return new DatabaseTableManager($this, $tableNameFromArgument)) so i do not have to pass db object every time. In DatabaseTableManager class, i built some queries to make my job easier.

E.g. to insert a record to a table;

$DB = new Database(...);
$myTable = $DB->GetTable('myActualTableNameInDatabase');
$myTable->Insert( array('col1' => 'val1', 'col2' => 'val2') );

So i use this class a lot in my other classes. Naturally all these classes become dependent to DatabaseTableManager class. What is the better solution?

Answer 1

What is the better solution?

What is the problem? :) So first of all from the standpoint of a general design it's said that we benefit from not introducing global static state. This disqualifies the singleton and using global variables.

This reduces the burden to make a choice a lot. Passing the needed Mysqli connection object into the class that needs it via it's constructor is fine. If you're concerned about "passing it all the time", define a place where you create these objects.

You've already done that in fact, for the "table manager" (maybe manager is not such a good term (it does not manage the tables in the database, it just represents them), but let's focus on the structure first). That class will give birth to objects that represent a table.

For that part of your application that is consuming these, there is no need to even know about which kind of database lies behind, because you've encapsulated that detail.

Naturally the table manager itself still needs to have that knowledge. However this is no problem, because you could change that in a central place if you would need to change that.

So actually I must say, even you're keen to look for problems, what you create actually looks pretty well.

Sure, as always you can run into problems, however if the way you make use of the database in your application is generally table based, this does not look that wrong to me. The pattern you've implemented might go into the direction of Active Record. It is known that this is suitable for small to medium sized applications that have Transaction Scripts.