On Tue, Sep 23, 2008 at 7:30 PM, Nathan Nobbe <[EMAIL PROTECTED]> wrote: > On Tue, Sep 23, 2008 at 5:25 PM, Eric Butera <[EMAIL PROTECTED]> wrote: >> >> I generate my data access objects too. It goes against my better >> judgment, but performance wins out in this specific situation. > > getting off the point of the thread (i could care less :D), but have you > seen the model taken by qcodo, propel (and likely others) where the > generated layer is extended, so that subsequent re-generation does not > interfere w/ customizations on the generated library? > > -nathan >
I have looked at Propel several times and I'm quite close to jumping on that bandwagon. The last time I was looking I decided against it though since it required a big base library to run properly (at least I think it was that, could be wrong). I do really like the idea of having something else take care of the DAO business for the most part. One less problem, right? My little generator just does the basic load, save (which calls update/insert based on pk), delete. From there I hand write out the actual fetch statements. I have some templates to ease the burden of doing some of the more repetitive queries, such as the ones that require pagination. I think it is very important to craft data fetching SQL statements though since that is usually the largest bottle neck of the system. After looking at that Qcodo framework for a second I've actually made another generator that creates the management side MVC pages to work off of a table too. That is an interesting idea though extending the generated classes to get around customizations. I was thinking about trying to come up with a way of doing a diff to handle this in my own generators. It is easy enough to just copy the basic methods and paste them over my current ones though. I hardly ever find myself adding new fields to tables once a job is complete so I haven't felt the motivation to do it yet. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
