Question

What is the benefit of using singleton instead of global for database connections in PHP? I feel using singleton instead of global makes the code unnecessarily complex.

Code with Global

$conn = new PDO(...);  function getSomething() {     global $conn;     .     .     . } 

Code with Singleton

class DB_Instance {     private static $db;      public static function getDBO()     {         if (!self::$db)             self::$db = new PDO(...);          return self::$db;     } }  function getSomething() {     $conn = DB_Instance::getDBO();     .     .     . } 

If there’s a better way of initializing database connection other than global or singleton, please mention it and describe the advantages it have over global or singleton.

Answer 1

I know this is old, but Dr8k’s answer was almost there.

When you are considering writing a piece of code, assume it’s going to change. That doesn’t mean that you’re assuming the kinds of changes it will have hoisted upon it at some point in the future, but rather that some form of change will be made.

Make it a goal mitigate the pain of making changes in the future: a global is dangerous because it’s hard to manage in a single spot. What if I want to make that database connection context aware in the future? What if I want it to close and reopen itself every 5th time it was used. What if I decide that in the interest of scaling my app I want to use a pool of 10 connections? Or a configurable number of connections?

A singleton factory gives you that flexibility. I set it up with very little extra complexity and gain more than just access to the same connection; I gain the ability to change how that connection is passed to me later on in a simple manner.

Note that I say singleton factory as opposed to simply singleton. There’s precious little difference between a singleton and a global, true. And because of that, there’s no reason to have a singleton connection: why would you spend the time setting that up when you could create a regular global instead?

What a factory gets you is a why to get connections, and a separate spot to decide what connections (or connection) you’re going to get.

Example

class ConnectionFactory {     private static $factory;     private $db;      public static function getFactory()     {         if (!self::$factory)             self::$factory = new ConnectionFactory(...);         return self::$factory;     }      public function getConnection() {         if (!$this->db)             $this->db = new PDO(...);         return $this->db;     } }  function getSomething() {     $conn = ConnectionFactory::getFactory()->getConnection();     .     .     . } 

Then, in 6 months when your app is super famous and getting dugg and slashdotted and you decide you need more than a single connection, all you have to do is implement some pooling in the getConnection() method. Or if you decide that you want a wrapper that implements SQL logging, you can pass a PDO subclass. Or if you decide you want a new connection on every invocation, you can do do that. It’s flexible, instead of rigid.

16 lines of code, including braces, which will save you hours and hours and hours of refactoring to something eerily similar down the line.

Note that I don’t consider this ‘Feature Creep’ because I’m not doing any feature implementation in the first go round. It’s border line ‘Future Creep’, but at some point, the idea that ‘coding for tomorrow today’ is always a bad thing doesn’t jive for me.