PDO help

Hi Robert,

Where did you read that you shouldn't extend the PDO class? I have personally done this as it creates code that's much easier to move around because of how modular/abstract it is.

I agree with Chris. I put my database code into one class, in one file and just require the file on a page that needs the connection.

Here is an example file and class that I use, just to show what it looks like.

<?php

    class Model {

        private $host   = "localhost";
        private $db     = "testing";
        private $user   = "testing";
        private $pass   = "testing";

        public function connect($host, $db, $user, $pass) {
            // connection code          
        }

        public function insert_into($table, $data) {
            // insert an associative array of data into table
        }
    }

    /*
        Usage:

        Model::connect();
        Model::insert_into($users, $logs);

    */

?>

There have been a lot of different places with the same sort of advice, never extend or wrap the PDO class as it just creates problems and throws away the good parts of PDO.

http://community.sitepoint.com/t/extending-pdo-class/7155

A comment from there too:

A while ago I was facing the same situation and found the hard way that it's not a good idea to extend PDO. A better way would be to write a wrapper class for PDO. It's fine to extends PDOException but not PDO classes.

http://codereview.stackexchange.com/questions/29362/very-simple-php-pdo-class

•Building an abstraction class on a user-friendly raw-API like PDO is, IMHO, like a broken pencil: Pointless

•Extending PDO means you don't have to create pass-through methods that call the wrapped API (like creating a prepare method), but it does mean there is a chance you'll have to refactor your code whenever PDO changes

•If you still feel like using a wrapper object, either consider wrapping it around something less well known, but in some respects better (mysqli_* is what I'm hinting at), but implement the magic __call and, if required __callStatic methods.

•Again, if you're going to procede: work on an entire abstraction layer, that allows for users to map tables to data models, and take it from there. Ensure that those data-models can be used easily to build HTML forms, for example in order for those forms to be linked to the DB in the blink of an eye, bot don't forget about sanitizing your data, of course.

http://grokbase.com/t/php/php-general/127d91638c/pdo-extend-or-encapsulate

I encapsulated it in my own database class. One reason for that is that the PDO "class" is really two classes, which is fine for low level drivers but not production code that I have to use daily. A second reason is that many of the methods are not really necessary in a production environment.

The three above are just some examples there are many many posts on it all but just as I think, ok lets wrap it I read a comment on how bad that is, then when I think actually extending it would be better I read another article or comment that says that's a bad idea too.

I cant seem to find the correct way to do it and from all the reading I havnt seen a good alternative to wrapping or extending either.

From the posted grokbase link, I agree with this comment

Use encapsulation: When a class has a "has-a" relation-ship with other class you should use encapsulation. For example, If MyDB is a class that "has-a" pdo driver in it, then PDO will be encapsulated inside MyDB class. This is also called containment. MyDB should contain PDO.

I choose to 'wrap' PDO functionality because I'd rather call a higher-level function that abstracts away the messiness of database interactions. I cannot be convinced that wrapping or encapsulating functionality is a bad thing. Code re-usability is a good thing.

<?php

// I'd rather write
Model::connect();

// that calls my wrapper
public function connect($host, $db, $user, $pass) {
    try {
        $dbh = new PDO("mysql:host=$host;dbname=$db;", $user, $pass);
        $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    } catch(PDOException $e) {
        echo "Could not connect to the database.<br>" . PHP_EOL;
        echo $e->getMessage();
        exit;
    }
    return $dbh;
}

// over having to write that code each time

?>

Personally, I must say that close to all PDO derived/based classes I've seen so far suffer from the same problem: They are, essentially, completely pointless. Let me be clear: PDO offers a clear, easy to maintain and neat interface on its own, wrapping it in a custom class to better suit the needs of a particular project is essentially taking a decent OO tool, and altering it so that you can't reuse it as easily in other projects.

The stack answer by the same guy that wrote the above comment is a rather good read.

The more I read the more unclear it becomes though.

[...] and altering it so that you can't reuse it as easily in other projects.

My code is reusable. My higher level function accepts arguments for host, db, user, and pass.

The function I posted earlier for insert_into was not initially designed to be re-usable, but can easily be fixed by accepting a db connection instead of calling Model::connect() from within itself for a database handle.

<?php

// change this
public function insert_into($table, $data) {
    // insert an associative array of data into table
}

// to this
public function insert_into($dbh, $table, $data) {
    // use the passed in $dbh to insert an associative array of data into table
}

// call it like this
$dbh = Model::connect($host, $db, $user, $pass);
Model::insert_into($dbh, $table, $data);

// done, and reusable

?>

Im not saying your code is not re-usable at all, what I am saying is that from these articles and posts ive found online and have read, both extending and wrapping seems to have its downsides and im not too sure on which way I should go. I can only assume I need to follow one of these option as ive not seen anything else suggested as of yet and was wondering if anyone here knew anything better.

I was in the process of writing a class and thought I should check what others use to give myself a better idea of what I need and how I should use it but then got a shock when the first things I read was not to extend or wrap, the more I read the more confusing it got for me.

Yep, sorry, I didn't mean to make you feel defensive. I understand the quotes are from articles and you're trying to figure out which way to go with your code.

While I've been opinionated on this matter, it really doesn't matter too much - unless you're working for someone who has an expectation of if being done a certain way. But, on your own, if it works, then great! Try not to get too caught up in which way is best.

I understand, I didn't mean to come across defensive, im always happy to read what others have to say as most know a lot more than myself.

Not too sure how this idea stands but would making a PDO object and storing it in a global variable work?

That doesn't really apply here though Tom, this is more a question on what is the right way to go about something as reading blog posts and places like stack has confused me more than help me. I don't have an opinion because I don't hold enough knowledge to form one.

I don't want to get half way though a project to then realise I've made a huge mistake that could of been avoided by simply asking a question and getting information on the subject.