-- Paul M Jones <[EMAIL PROTECTED]> wrote (on Thursday, 06 November 2008, 09:26 AM -0600): > > On Nov 6, 2008, at 08:37 , Matthew Weier O'Phinney wrote: > > > -- Steve Klabnik <[EMAIL PROTECTED]> wrote > > (on Thursday, 06 November 2008, 09:23 AM -0500): > > > On Wed, Nov 5, 2008 at 6:23 PM, Matthew Weier O'Phinney > > > <[EMAIL PROTECTED]> > > > wrote: > > > > > > There's not. I'm not entirely sure why Zend_Db_Table does not > > > implement > > > this, though my understanding is that there are some sound > > > architectural > > > reasons not to do so. I've often created such a method myself, > > > though, > > > > > > > > > > > > Again, there's not, and again, uncertain as to why. I've often > > > implemented such functionality for my own models, however. > > > > > > > > > I'm pretty sure that Cake tries to emulate the ActiveRecord pattern, > > > and Zend does not. I did a quick search, and it seems like some > > > ActiveRecord-ish stuff was proposed for Zend back in 2006, but never > > > took any ground? > > > > Yes. The reason was that PHP currently does not support a pure > > ActiveRecord implementation due to lack of late static binding (LSB -- > > which will be available in PHP 5.3.0). > > "Pure" is in the eye of the beholder. ;-) > > The Rails Active Record implementation uses static finder methods, and > Cake tries to emulate that using instance methods. Fowler [1] notes > that static finder methods "typical", but he goes on to say: > > "However, there's no reason that you can't separate out > the find methods into a separate class, as I discussed > with Row Data Gateway (152), and that is better for > testing." > > So it seems perfectly acceptable, from an implementation and "purity" > point of view, to have a Table Data Gateway (the finder) return Active > Records. > > Regardless of the *name* of the row class, if it can contain business > logic that operates on the row, it can fairly be called an active record > implementation.
Right. I was just stating the officially stated reason for why ActiveRecord wasn't included originally. :) An interesting thing to note is that a Row Data Gateway acts very similarly to the ActiveRecord; the primary difference is that an ActiveRecord object contains the data access logic, while the Row Data Gateway leaves that aspect to its parent Table Data Gateway, proxying to it. When it comes down to it, for most cases you'll use them in almost exactly the same way -- which I think is what you were getting at in that last sentence. > (FYI, Solar <http://solarphp.com> works in a similar manner, with a > table/model class to represent the table, and a record class to > represent the resulting record (and its related records, if any). I > might argue that the Solar implementation is more sophisticated, but > I've self-promoted enough at this point. ;-) For the record, for those of you newcomers... PMJ's Solar project is top-notch. Additionally, PMJ worked at Zend for a short while, and contributed the original Zend_View and Zend_Db_Table implementations to ZF. Just thought I should give credit where credit is due. :) -- Matthew Weier O'Phinney Software Architect | [EMAIL PROTECTED] Zend Framework | http://framework.zend.com/
