Member Avatar for Member #46692

Yeah, basically if you're using PDO for dbs, and you're using a framework which uses MVC, how would you change the code?

I was assuming you would just use the classes in the MVC but then you wouldn't be using the benefits of PDO?

Does that make sense?

  • 2 Contributors
  • 1 Reply
  • 601 Views
  • 8 Hours Discussion Span
  • Latest Post Latest Post by jkon

Dani AI

Generated

PDO and MVC are complementary: PDO is the database API and MVC is an architecture. As pointed out, using PDO inside an MVC app is normal — the real question is how to wire it so the model layer gets PDO's benefits (prepared statements, transactions, consistent driver API) without coupling the controller or global state to the DB.

A recommended approach:

  • Instantiate and configure a single PDO instance at app bootstrap (front controller or DI container). Set sensible options: PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION and a default fetch mode.
  • Inject that PDO instance into models (or into thin repository/DAO objects) rather than calling new PDO() all over the place or running SQL in controllers.
  • Prefer composition (a small wrapper or repository interface) over extending PDO. A wrapper is easier to test/mocking, keeps SQL isolated, and makes swapping an ORM or DBAL simpler later.

Example (minimal pattern):

<?php
$pdo = new PDO($dsn, $user, $pass, [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
]);

class BaseModel {
    protected $db;
    public function __construct(PDO $db) {
        $this->db = $db;
    }
    protected function fetchOne($sql, $params = []) {
        $stmt = $this->db->prepare($sql);
        $stmt->execute($params);
        return $stmt->fetch();
    }
}

class UserModel extends BaseModel {
    public function find($id) {
        return $this->fetchOne('SELECT * FROM users WHERE id = :id', ['id' => $id]);
    }
}

Cautions and quick tips: always use prepared statements and bound parameters (no string interpolation), wrap multi-step changes in transactions, surface PDO exceptions to a central error handler, and keep SQL inside the model/repository. If using a framework, register PDO or its wrapper in the service container so controllers stay thin and models retain full PDO benefits.

Member Avatar for jkon

PDO is a consistent interface for accessing databases in PHP while MVC is a software design pattern. Stating that , I believe that is clear that you can have MVC without the use of PDO or with it , and of course the use of PDO in a MVC or outside it.

I strongly believe that PDO (with prepared statements) is the best way PHP has to connect and make requests to a DB. Also I believe that MVC and its variations is still the cleanest way to build a web application and more over in the OOP world it is now a common ground. So using PDO in a PHP project that is build in MCV design pattern is obvious to me.

One of your phrases me really puzzled me “I was assuming you would just use the classes in the MVC but then you wouldn't be using the benefits of PDO?” what do you really mean? In what classes are you referring to?

There are many ways to use PDO in a MVC architecture, it all have to do of how you define the Model and it’s db layer (Of course some may have use a db layer in the Controller but I really think that this eliminate some major benefits of MVC). What I think as the logical way to go (without canceling other approaches) is having your DB object (that is a child of PDO) instantiating in the Controller (or in the Front Controller) and pass it to the Model where it will be used to return results (objects or list of objects) or to make modifications to the DB.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.