Buddy, if you're ever make your way through Saskatoon give me a shout and I'll buy you a beer.
Given your consent, could we essentially copy / paste this somewhere into the book? Maybe in http://book.cakephp.org/view/66/models under a separate heading "ORM"? Ralph On Jun 24, 7:49 am, "Jonathan Snook" <[EMAIL PROTECTED]> wrote: > > 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
