Adding something to the book about the A/ORM approach along with addressing the usual PHP4 debate is probably a good thing. I'd probably look to add it in the 1.0 or 2.0 section of the book. A copy/paste probably isn't a good idea but it could be rewritten to be a better fit for the book. I'll see about adding it in within the next day or two.
On Wed, Jun 25, 2008 at 11:01 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 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 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 -~----------~----~----~----~------~----~------~--~---
