Re: is my approach to using DB_DataObject sensible?

From: Date: Wed, 28 Sep 2005 21:48:08 +0000
Subject: Re: is my approach to using DB_DataObject sensible?
References: 1 2 3  Groups: php.pear.general 
Request: Send a blank email to pear-general+get-21139@lists.php.net to get a copy of this message
On 9/28/05, Roger Rohrbach <roger@ecstatic.com> wrote: > Thanks, Justin. Some comments on your response: > > > 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. > > My schema is in flux, and leaving the auto-generated classes alone allows > me to update them automatically when the schema changes, rather than > maintain them by hand. > You can alter the autogen classes while still updating the schema automatically. Just put your edits outside of the auto-gen comments. > > > * I want to override the fetch() method, as suggested in the > documentation, to add properties that are not stored in the > underlying tables > > > I now realize I can do this without extending the base classes (I'd > confused them with the DB_DataObject class that originally defines this > method). But I still like keeping my application code out of the auto-gen'd > classes. Getting the role of a user is hardly application code. It's data code. > > > > /* > * 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. > > The docs say calling the factory is the preferred way to both load classes > and instantiate. I looked at the source and decided it doesn't do anything > significant, so I'm just using require_once() as you suggest. > > Yes, using ::factory is the preferred way to load *and* instantiate. If all you're doing is loading then factory is overkill. > > > // override fetch() to add 'role' to the object: > > function fetch() { > > if ($result = parent::fetch()) { > > $this->role = $this->getLink('role_id'); > } > > return $result; > } > > 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'm aware of the cost, but the User object is presently a singleton > (representing the logged-in user). When I add user management or other > functionality that manipulates sets of users, I'll likely change the class > to fetch the related data on demand. I won't make the app call getLink(), > though; I'll add a method like "role()" that fetches (and caches) the > related data, by calling getLink(). Ideally, my app will only use get(), > find(), fetch() etc. > -- Justin Patrin

« previous php.pear.general (#21139) next »