On Fri, 2006-03-03 at 14:53, Andreas Korthaus wrote:
>
> - use a factory/singleton, which is not so much better than a global 
> variable (and again, what about config-data?).

I use a global configuration to register database connection params.
InterJinn uses something like the following:

$GLOBALS['interJinn']['databases'] = array
(
    'carnageWeb' => array
    (
        'type'     => 'mysql',
        'host'     => 'wocmud.org',
        'user'     => 'me',
        'password' => 'noyou',
        'db'       => 'carnage_web'
    ),

    'carnage' => array
    (
        'host'     => 'wocmud.org',
        'user'     => 'me',
        'password' => 'notyouagain',
        'db'       => 'carnage'
    ),

    'carnageForum' => array
    (
        'host'     => 'wocmud.org',
        'user'     => 'me',
        'password' => 'notyouyetagain',
        'db'       => 'carnage_forum'
    ),

    'default'   => 'carnageWeb',
);

This is consumed by the database manager which is a singleton/factory
that uses connection pooling.

<?php
    $mDb = &$this->getServiceRef( 'dbManager' );

    $db = &$mDb->getConnectionRef();
    $db->query( 'blah blah blah' );

    $db2 = &$mDb->getConnectionRef();
    $db2->query( 'bleh bleh bleh' );

    $db3 = &$mDb->getConnectionRef( 'carnageForum' );
    $db3->query( 'bleh bleh bleh' );

    $db->free();
    $db2->free();
    $db3->free();
?>

In this way all database connections are named such that if something
changes in the future, whether it be the name of the database, the type
of database server, the port, whatever, my code shouldn't need to change
-- only the configuration. Additionally since I retrieve from a pool, I
only ever use as many connections as I need at a time. Be that 1 or 3 or
5. Additionally I know that when I retrieve a second database instance
it's not going to clobber the query from the first request.

I advocate use of the $GLOBALS array for configuration information that
remains static and only when the purpose is clearly defined and well
named such that you can be very sure that you won't run into naming
conflicts in the near future. This is why I use an interJinn sub array
within the globals to segregate InterJinn specific configuration vars.
I'd advocate using constants but they don't support arrays, or at least
not as far back as I maintain compatibility. Why the PHP guys didn't
foresee constant array values is anyone's guess *lol*.

You'll also notice I retrieve the factory/singleton by means of named
service. This avoids most of that interface/inheritance bullshit that
Java gets mired in (and PHP5 has embraced *hahah*). As long as the
expected methods exist then any class can be dropped in as a replacement
via the service registry, whether it extends, implements, burps, or
farts the original class -- or not :)

Cheers,
Rob.
-- 
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to