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.
(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. ;-)
[1] Fowler, Martin. "Patterns of Enterprise Application Development."
Page 161.
--
Paul M. Jones
http://paul-m-jones.com/
