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