1

I am trying to get a database instance via any model-class that uses the database.

This is ideal in my opinion:

class UserAuthenticator 
{
    private $db;
    private $customer;

    public function __construct(Database $db, Customer $customer)
    {
        $this->db       = $db;
        $this->customer = $customer;
    }
}

Using a dependency injection.

But my team refuse to use dependency injections.

Which of the 2 options should be better and why?

Option 1: Just getting the instance of the database directly only in models that need the database.

class UserAuthenticator 
{
    private $db;
    private $customer;

    public function __construct()
    {
        $this->db       = Database::getInstance();
        $this->customer = Customer::getInstance();
    }
}

Option 2: Having a "general" Base class, that will extend all models, forcing them to use the database (which isn't a must in models right?)

namespace MyApp\Models\Base;
use MyApp\Core\Database as db;
class Database {

    protected $db;

    public function __construct() {
        $this->db = db::getInstance();
    }
}


use MyApp\Models\Base\Database as Base;
class UserAuthenticator extends Base
{
    private $customer;

    public function __construct()
    {
        parent::__construct();
        $this->customer = Customer::getInstance();
    }
}
  • 1
    "my team refuse to use dependency injections" What does that mean? They don't want functions to have parameters? – Stop harming Monica Feb 28 at 13:37
  • 1
    They don’t refuse DI, they refuse a container – king-side-slide Feb 28 at 16:16
  • I'm personally curious why they don't want a container. The usual objection I'm aware of is that it resembles too much as a bunch of global variables but so do singletons. I also assume is not because of the work involved because there are several open source ones, ready to be used. – Rad80 Mar 1 at 12:19
2

I am one of those who think that Singleton is an anti-pattern, so I'd say I like your implementation best and I'd also recommend your team to take one existing MVC framework rather than using up time reinventing a (usually worse) wheel.

Now that this is out of the way, I'll actually answer the question.

Option 2 looks better. DRY is important here because if anything changes about the instantiation of your DB you can change it in one place. This might be the difference between being able and not able to implement such a change in the future.

PHP has traits, which would be much much better than a base class here. If your PHP version is high enough (>=5.4.0) try to use use those.

  • 1
    I'd agree with not reinventing the wheel. I'd be curious as to why they're engineering a new MVC framework to compete with the many existing (although who knows, maybe this is what the company does, and what they're being asked to do). – Scuba Steve Feb 28 at 21:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.