On Tue, Jun 24, 2008 at 8:36 AM, Howie <[EMAIL PROTECTED]> wrote:
> I guess I'm being a little pendantic about the Model, but then again,
> I did lose time trying to understand it, as I's asumed it did much
> more than it appears to do. What happens under-the-hood is great, and
> keeps the code clean, but it's not ORM as I understand it.
Agreed. It's not typical ORM, certainly not when coming from the world of Java.
> From my Java OO experience, the real benefits gained from ORM is
> mapping relational data back into into an object graph.
That's not really the benefit, per se. How do you work with data in
Java? Using objects and Java data types, of course. The ORM literally
maps the relational to the objectal (and vice versa). However, the
benefit is not the mapping part in and of itself. The benefit is in
the ability to work with data in a format that's native to the
language, and in Java, that's as objects.
In PHP, arrays are at the very core of the language, although OO
approaches have slowly been seeping their way into the language. What
CakePHP has done is take ORM and apply it to the PHP paradigm. What
you get is an A/ORM (Array/Object relational mapping -- since CakePHP
technically uses both).
> If my model is to become thick with business logic, then it should be able
> to operate as a class instance.
> Can my Toy class encapsulate logic such as:
>
> if ($this->price < 9.99) then {.. } ?
Yes, your Toy model class can—and should—encapsulate that logic. Make
that model thick. That logic is normally applied where it matters
most: when attempting to push the data from the model back to the
database either via the validation phase or via the beforeSave
callback (as opposed to getter/setter methods which I'm guessing is
what you're thinking). The lifetime of the object is too short-lived
to need anything more complicated. The purpose of the A/ORM in CakePHP
is to act as a conduit to the database (or whatever the final
datasource is).
> The examples of Fat model that I've seen all seem statelss with
> repsect to the object attributes.
PHP is stateless. A user initiates an action and expects a quick
response. PHP's (and CakePHP's) job is take the data, validate the
data, store the data, and then formulate a response. After that, it's
like nothing happened.
I don't see any advantage (or disadvantage) to using an ORM in the
traditional sense and, to get back to your original point, calling
CakePHP's approach "half-baked" comes across as derogatory when
ultimately, you have all the facitilities available as you do with
traditional ORM. Every example you've shown so far is possible (and
designed to be easily done) with CakePHP.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CakePHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---
