Re: is my approach to using DB_DataObject sensible?

On 9/26/05, Roger Rohrbach <roger@ecstatic.com> wrote: > Hello, > > I'm using DB_DataObject for the first time. After playing around with > it a bit, and given the following: > > * I don't want to edit the auto-generated classes Why not? This is the sensible way to do things. > * I want to define behaviors for my database objects > * I want to override the fetch() method, as suggested in the > documentation, to add properties that are not stored in the > underlying tables > > I've decided to extend the auto-generated classes and use the new > classes in my application. > > As a concrete example, here's the User class for my Web app: > > <?php > > require_once('DB/DataObject.php'); > > > /* > * Load the base class (DataObject_User). There's no way to do this > without > * instantiating, but we discard the resulting object because we're > extending > * the class. > */ > > DB_DataObject::Factory('User'); You don't have to use factory here if all you're doing is loading the class. You can use require_once(). However, I think that altering the auto-gen class would be a much better solution. > > > class MyAppUser extends DataObject_User { > > var $role; > > > // override fetch() to add 'role' to the object: > > function fetch() { > > if ($result = parent::fetch()) { > > $this->role = $this->getLink('role_id'); > } > > return $result; > } > } > > ?> > > > 'Role_id' is the foreign key of a UserRole table. > Are you sure you want to do another query every time you fetch? This is going to cause a whole new query to the DB, which can cause slowness. This is especially a bad idea if you're not using this data every time you fetch a User record. It would be better to just getLink in the calling script. > I'd like to get feedback on whether this is a sensible approach. In > particular: am I correct in saying that DB_DataObject::Factory() is the > only way to load the class? I can't extend the class until it's > loaded. It seems a bit inelegant, but I've not seen any other way to do > this. > > Comments welcome. > -- Justin Patrin