aggregation class ideas?

Hi

I have many classes that use database connections to fetch data and
manipulate on it. I also have database abstraction class that is
handling all the database queries and so forth.

Usually all my classes take instantiated database object as the first
parameter to constructor so they know what database to use:

public function __constructor(Database $db, $var1, $var2){

if($db->is_connected()){
// construct class
} else {
throw new Exception('Bla bla bla');
}
}

then in the script i do:

try{
$db = DB::create_DB($DB_settings);
$u = new theOtherClass($db, $var1, $var2);
} catch (...)

It works great if the class uses only one database connection. I
establish connection pass the object to "theOtherClass" and I'm happy :)

Now I'm designing class that will be aggregating at least 5 other
classes that might use different databases.

I don't want to create 5 objects and then pass them to this class'
constructor. So I'm looking for better way to do it.
Any ideas?

Ralph

PS: I was thinking of passing array with all the settings to the
constructor and then creating objects internally based on info in an
array. But don't like the idea so much.

Ralphz wrote:
> Hi
>
> I have many classes that use database connections to fetch data and
> manipulate on it. I also have database abstraction class that is
> handling all the database queries and so forth.
>
> Usually all my classes take instantiated database object as the first
> parameter to constructor so they know what database to use:
>
> public function __constructor(Database $db, $var1, $var2){
>
> if($db->is_connected()){
> // construct class
> } else {
> throw new Exception('Bla bla bla');
> }
> }
>
> then in the script i do:
>
> try{
> $db = DB::create_DB($DB_settings);
> $u = new theOtherClass($db, $var1, $var2);
> } catch (...)
>
> It works great if the class uses only one database connection. I
> establish connection pass the object to "theOtherClass" and I'm happy :)
>
> Now I'm designing class that will be aggregating at least 5 other
> classes that might use different databases.
>
> I don't want to create 5 objects and then pass them to this class'
> constructor. So I'm looking for better way to do it.
> Any ideas?
>
> Ralph
>
> PS: I was thinking of passing array with all the settings to the
> constructor and then creating objects internally based on info in an
> array. But don't like the idea so much.
>

If you need 5 different databases, you are going to need 5 different
objects representing them. You can pass them individually or as an
array. Or the class aggregating them can create them, if no one else
needs them.

There is nothing wrong with passing 5 parameters to a function (or
constructor), if that's what you need.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Feb 23, 3:38 am, Ralphz <ralphza...@sbcglobal.net> wrote:
> Hi
>
> I have many classes that use database connections to fetch data and
> manipulate on it. I also have database abstraction class that is
> handling all the database queries and so forth.
>
> Usually all my classes take instantiated database object as the first
> parameter to constructor so they know what database to use:
>
> public function __constructor(Database $db, $var1, $var2){
>
> if($db->is_connected()){
> // construct class
> } else {
> throw new Exception('Bla bla bla');
> }
>
> }
>
> then in the script i do:
>
> try{
> $db = DB::create_DB($DB_settings);
> $u = new theOtherClass($db, $var1, $var2);
> } catch (...)
>
> It works great if the class uses only one database connection. I
> establish connection pass the object to "theOtherClass" and I'm happy :)
>
> Now I'm designing class that will be aggregating at least 5 other
> classes that might use different databases.
>
> I don't want to create 5 objects and then pass them to this class'
> constructor. So I'm looking for better way to do it.
> Any ideas?
>
> Ralph
>
> PS: I was thinking of passing array with all the settings to the
> constructor and then creating objects internally based on info in an
> array. But don't like the idea so much.

My suggestion is to refactor your code. This may not be feasable
based on your constraints, but what you are describing smells like it
might need a redesign to not let it become a monster.

First, I think you should decouple the database objects from the
domain classes, so that your domain objects are just that -
abstractions of the objects present in your problem domain. This way,
these objects don't know or care about how they will be persistently
stored, this will be handled by mechanisms that will work on them (it
isn't their job to do the database work). If you require 5 unique
database connections in your application, perhaps a better method
would be to store your database connections (each as their own object,
as Jerry mentioned) in either a registry and/or have your database
objects implement a singleton pattern, so you don't have to pass them
around.

Now that your domain objects don't know anything about databases and
how they relate to the relational model, you need to create a
mechanism to do this (object-relational mapper). Depending on your
situation, the active record, table gateway, or data mapper patterns
may be a good place to start looking (I personally prefer the data
mapper pattern even in simple situations, its just cleaner to me.
This will handle converting your objects to and from the database.
Since you are using a database abstraction layer, if your 5 databases
share the same schema (I doubt it) than all you need to do is pass the
correct database connector and the appropriate object you wish to do
work on to the data mapper and it will update the record in the
appropriate database. If the schema are different, you should create
a data mapper for each schema.

I realize this might be much to handle in a short response, so I
included some references to further explain the theory and practice.

Hope this helps,

Steve

References:

singleton pattern: http://www.phppatterns.com/docs/desi...gleton_pattern
data mapper pattern: http://www.martinfowler.com/eaaCatalog/dataMapper.html
list of PHP ORM tools: http://en.wikipedia.org/wiki/List_of...pping_software

Thank you very much for your response.

I was thinking about what you said and come up with this solution:

I added constructQuery method to database abstraction class that takes
configuration file with descriptions of database tables and columns.
Something like:

$data['f'] = array(

'login' => 'log.login,log.pass',
'address' =>
'dos.home_street,dos.home_city,dos.home_state,dos. home_zipcode');

$data['t'] = array(
'login' => 'user_login_tbl log',
'address' => 'user_dossier_tbl dos');

$data['glue'] = 'user_id'; // Column that 'glues' two tables.

Based on this configuration array DB abstraction class can create SLQ
queries based on underlying database.

All my classes use factory class to instantiate the objects.

$user = Fact::User(15);

This pice of code would create object user and fetch data about user
with id 15. By default it would fetch only subset of the user data like
login, password.

$user->setPassword('newPass');

That would change the password of the user and so on.

All the database queries are constructed in the fly by database object
that is passed to User class by factory class. So inside the User class
our update password would trigger SQL update query constructed based on
underlying database and $data array describing tables and rows.

Ralph