TalkPHP - Your oppinion counts

TalkPHP (http://www.talkphp.com/forums.php)

- Advanced PHP Programming (http://www.talkphp.com/advanced-php-programming/)

- - Your oppinion counts (http://www.talkphp.com/advanced-php-programming/2020-your-oppinion-counts.html)

Your oppinion counts

Howdy everybody. So, I have a DAL system setup, right? I need your thoughts about its implementation, and whether you would want to modify the factory or the interface if you were to develop an Oracle driver for instance - or any other database driver - (it's all about extensibility):

- Interface:

PHP Code:


		
			
interface DB_Driver
{
    public static function getInstance();
    public function connect();
    public function select( array $a );
    public function insert( array $a );
    public function update( array $a );
    public function delete( array $a );
}

- Factory:

PHP Code:


		
			
final class DB
{
    public static function getInstance( $type = 'mysql' )
    {
        // require the database driver
        self::$instance =& mysql_driver::getInstance();
    }
}

- and, of course, the mysql driver (the default one):

PHP Code:


		
			
class mysql_driver implements DB_Driver
{
    // singleton, implements the interface methods and its own methods (if you need anything, just write it :)
}

Only some excerpts are shown here, the real code doesn't matter that much. The idea itself is more important than the actual code.

The question I'd have to ask is with the abundence of high-quality tested database abstraction libraries about nowadays (including PDO built into PHP itself), is it worth rolling your own?

But, if you do want to roll you own, my suggestion would be to use one based on ActiveRecord. For an implementation example, take a look at CakePHP.

Alan

Yes, it is worth. Why? Simply because this system will be part of a proprietary system, but I want to provide a gate for developers to write their own drivers if they want/need to use some other database such as Oracle or SQLite or Postgre, etc. I've thought of the Active Record pattern before writing the actual system and I've decided that an array-based library is faster and less memory consuming than an object-based one (it's enough that the whole system is almost fully object oriented).

So why don't I use some free software (like an ORM or any other library from the internet), you would ask. Simply because people will pay for this software. And free software doesn't really work in a proprietary system. I use my own license, I have taken time to create the software, and I'm not risking getting sued over some stupid library (and this is very interpretable, believe me). The only thing that concerns me right now is that the system will be extensible - so if a developer wants to take a component or a library and plug it into the system, he can do just that without having to change the default libraries - which will be updated from time to time.

So, this is some kind of a review I need from other 'colleagues' :-P

Ok, each to their own :-)

One more thing to add to my original post though for the benifit of anyone else who is thinking of writing their own database class, if you are worried about speed, use PDO, it's much faster than a function wrapper class and provides support for every database system that PHP supports nativly. Also, the major downside of using a function wrapper system is that if you want to extend it to support other database servers in the future, you're stuck with writing all your queries in SQL92 which means you loose a lot of functionality such LIMIT.

Alan

I remember writing an article ages ago about this, ahh the good old days.

looks good to me m8, although you dont need to tell php to get a reference:

PHP Code:


		
			
self::$instance =& mysql_driver::getInstance();

as php5 passes objects around by ref automatically and infact (i believe) your code may produce a E_STRICT error (or is that just for the 'new' keyword? not sure on that), so

PHP Code:


		
			
self::$instance = mysql_driver::getInstance();

would achive the same ends.

apart from that all is good.

i also like to create my own DAL, gives me more control and is less bulky and cumbersome as others.

PHP might pass objects by reference automatically, but when I need the reference to a variable, I explicitly reference them, to make it more clear to me that I'm using a reference and not the object itself. And yes, this snippet:

Code:

$some_obj =& new TestClass();

would leave you with a fatal error and nothing more (because the object is just being created, it doesn't yet have a reference until the script steps through that line). My implementation doesn't throw any errors/warnings/notices, because the object is referenced correctly and exists in memory at that point.

Thanks for the feedback. So the system will stay :-D

Just a couple of points on your code, xenon.

Firstly, your code snippets in the first post don't show you declaring the $instance static member for the DB factory. Failing to declare that will result in a fatal error when you try to assign it the driver instance later on. Since you stated that your implementation doesn't throw any errors then I can only assume that you deleted it from your code sample in the first post to keep things short.

A useful addition for 'extensibility' as you put it, would be to make use of that argument for the DB::getInstance method. For example:

PHP Code:


		
			
if (class_exists($type.'_driver', TRUE))

{

    // assign instance of driver

}

So if the class isn't available, and cannot be autoloaded, you can throw a relevant exception or fall back on something else should you choose. Someone might decide that it's fun to call DB::getInstance('wobblybobblydb') which you don't have a driver for. At the moment it is hard-coded to use the MySQL driver which I'm sure you'll agree isn't particularly extensible.

Another point is that sketch was right about your driver instantiation producing an E_STRICT warning. The associated message is, "Only variables should be assigned by reference". The simple solution, unless you don't mind bending the strict standards from time to time, is just to not use the & and let PHP do its own job of passing around references to objects.

I think there might have been another point or two that I wanted to post about but the urge to find some lunch is taking over so I can't remember what those things were! As such, I'll leave things here.

Quote:

$some_obj =& new TestClass(); would leave you with a fatal error and nothing more

are you sure? this was standard procedure in php4, because the php4 object model didnt pass objects by ref, it made a copy, thus

PHP Code:


		
			
$pObj = new lolItsAClass();

means that there is a copy of the object being made, so to combat we have to tell the php interpreter that we want the reference and not the copy:

PHP Code:


		
			
$pObj =& new lolItsAClass();

in php5 this was updated so that the 'new' keyword automatically returned a reference to the newly created object and not a copy, hence the need for the 'clone' keyword (to replicate objects), i cant test my thorey because im at work.