|
|
|
#1 |
|
Messages: n/a
Hébergeur: |
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. |
|
|
|
#2 |
|
Messages: n/a
Hébergeur: |
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 ================== |
|
|
|
#3 |
|
Messages: n/a
Hébergeur: |
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 s, 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 |
|
|
|
#4 |
|
Messages: n/a
Hébergeur: |
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 |
|
![]() |
| Outils de la discussion | |
|
|