Database Access Layer as a static class or singleton?

PHP
1

Hi folks,

I’m relatively new to OOP and thoroughly enjoying learning all of these different architectures and design involved in OOP and have a question regarding the accessing of data. (I hope it’s not a stupid question!)

What are the benifits on accessing the database via a static class or a regular class (or even singleton pattern)?

For instance:


//Performing query using static database object
DB:init(HOST, USER, PASSWORD, DBNAME);
DB::query("SELECT...");

//Performing query using singleton pattern
$mysql= DBSingleton::getInstance(HOST, USER, PASSWORD, DBNAME);
$mysql->query("SELECT...");

Are there certain benifits with one and not the other (other than not having to instantiate the static class everytime)?

2

First, use [fphp=PDO]PDO[/fphp] rather than developing an all new db object. This will save some time.

Second, do not use a singleton. While normally you only will need one object, you’re painting yourself into an uncomfortable color without realizing it. What happens if you need to do an import/conversion from another database? The first time you need to have two connections to two different databases you’ll curse your decision to make your db object a singleton.

3

The other option is just as bad (if not worse…) than a singleton. Don’t use static methods like that, it makes for hard to maintain code with no extensibility.

Instead, create an instance of the object and pass it around. That way, your DB object can be substituted anywhere it is used.

4

That makes perfect sense about the Singleton, and as for PDO, I’m considering using this (either PDO or MySQLI) but at the same time I’m just trying to understand the pros and cons of either a singleton or static methods for future purposes and to broaden my knowledge of OOP.

Is passing an object from class to class really that much more practical than static methods? Being new to OOP, isn’t passing objects such as a database from class to class (for instance, most classes are going to require a database connection) going to argument confusion?

5

It depends how you’re defining practical.

If you want to hack something together that just works, then static methods are more practical.

However, if you want something that’s easily maintainable and allows for reusable code then passing an object into the constructor is better because:

-The object can be substituted during testing

-You have no way of knowing where in your code DB is being used. If it’s required in the constructor you can tell quickly whether a class has a dependency on it.

-A different instance of the same object could be passed instead (allowing you to have multiple database connections)

-A child object which inherits from your DB class (e.g. one which logs every query or uses a totally different type of database connection)

-If you’re using singletons/static methods you’re probably not using TDD, so using type hinting, your code will fail at __construct if the required object cannot be passed to it. Using a singleton or static methods your code will fail at the first occurrence of DB::query() which may not be code which is reached often.

-This can be avoided with singletons, but using DB::query() arbitrarily in the code, there is nothing to say the DB static properties are in the correct state for use. At least by initiating the object you can infer that any fully constructed instance of DB is in a usable state.

6

It does sound like passing the database object from class to class is going to be the best bet then. Thanks huge amount of taking the time out to explain the benefits to me :slight_smile: