在我看来，你正在尝试建立你自己的orm和实践是好的。对于大型项目，为了更舒适，可以考虑采用一些orm，比如条令、雄辩等（取决于框架）。
不使用依赖注入的方法可能需要在构造函数中示例化数据库对象本身。让我们给出一个使用单例来提供db对象的示例。

class Product {
    private $pdo = null;
    // other product properties here

    public function __construct() {
        // get db
        try {
            // set PDO object reference on this object
            $this->pdo =  PDOSingleton::getInstance();
        } catch (Exception $e) {
            error_log('Unable to get PDO instance. Error was: ' .
                $e->getMessage();
            // perhaps rethrow the exception to caller
            throw $e;
        }
        // query DB to get user record
    }

    // other class methods
}

// example usage
$product = new Product(1);

当使用依赖项注入时，可能会变成这样：

class Product {
    private $pdo = null;
    // other product properties here

    // pass PDO object to the constructor. Enforce parameter typing
    public function __construct(PDO $pdo) {
        $this->pdo = $pdo;
        // query DB to get product record
    }

    // other class methods
}

// example usage
// instantiate PDO object. This probably happens near beginning
// of code execution and might be the single instance you pass around
// the application
try {
    $pdo = new PDO(...);
} catch (PDOException $e) {
    // perhaps log error and stop program execution
    // if this dependency is required
}

// somewhere later in code
$product = new Product($pdo);

这看起来只是一个细微的差别，但是使用这种方法的开发人员喜欢它，因为它：
将消费类与如何示例化依赖关系的细节分离。为什么用户类必须知道要使用哪个单例才能获得它的pdo依赖关系？类应该关心的是如何处理依赖关系（即它有哪些属性和方法），而不是如何创建依赖关系。这更接近于oop中通常需要的单一责任原则，因为用户类只需示例化用户表示，而不必示例化其依赖项。
消除需要依赖关系的类之间的重复代码，因为在示例化/创建依赖关系时不需要每个类中的所有处理。在示例代码中，我消除了在构造函数中可能处理失败的db示例化的需要，因为我知道我已经有一个有效的pdo对象作为参数传递（如果我没有传递一个，我将得到无效的参数异常）。