NYCPHP Meetup

[Kenneth Downs]

Hans C. Kaspersetz wrote:
> I can't believe that my group is the only group on this list that has 
> implemented ORM.

One reason it is not that common is that it is a response based on 
experience with lots of biz apps.  A great many PHP programmers have 
never seen a biz app and never will.  There is a large group of 
programmers whose radar will never show any significant RM strategy.

Next is

>   If you have implemented ORM, what challenges did you face?

All of the challenges we faced stemmed from  the fact that all apparent 
parallels between classes and tables were illusory, misleading, and 
ultimately counter-productive.   Some colorful analogies that come to 
mind are: "Tables fit to classes like  fingers in light sockets." 

To swallow the red pill on this, all you have to do is inquire into the 
basic purpose of the various layers in a web app.  The DB layer is all 
about faithfully storing structured data.  Its interface is a simple, 
set-oriented declarative language called SQL.  The code layer is all 
about picking data up from one place and sending it to another, either 
from the browser (or other imput) to the db or vice-versa.  Most 
languages in this layer cannot efficiently do set-based operations.

The key here is to realize that the specs for these two layers are 
entirely different.  A database specification is an unordered list of 
definitions, while a program specification is an ordered list of 
actions.  The first mistake of ORM is to try to make a system where we 
can safely ignore these distinctions, forgetting of course that the 
distinctions are very useful and necessary.

Once you've decided to try to treat these two as if they were the same, 
it becomes impossible to get the interface right between them.  Consider 
the simple fact that it follows from their natures that the job of the 
interface is to arrive at set-based SQL commands in the one direction 
and to serve up the results of set-based SQL commands in the other.  But 
in the ORM mind you can never arrive at this simple truth because you 
are busy trying to figure out how to implement the declarative concept 
of a foreign-key in the step-by-step world of code.  

Now here OO theory comes to our aid.  OOP theory loves a cleanly 
encapsulated object with a useful interface.  The PHP/Apache layer is 
just such a thing, and the database another such thing.  They are very 
different kinds of things, and our OOP theory tells us they will fail to 
behave efficiently if we try to wrap a single interface around them, as 
ORM tries to do.

Another big example of this kind of thinking is ASP.Net, which tries to 
convince the programmer that he does not have to worry about the 
browser-server interface, he can safely ignore it. 

> And how did you solve them?  

I abandoned ORM completely and without regret and adopted an 
architecture that relegates jobs to the 5 elements of a web app 
(browser, server, db, browser-server interface, server-db interface) as 
is appropriate to each element, with no attempt to make any of them go 
away or act like one of the others.

> What compromises did you choose?

None.

>   Were they conscious or unconscious compromises?

I can't tell you about the unconscious ones :)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ken.vcf
Type: text/x-vcard
Size: 261 bytes
Desc: not available
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070126/211b2c68/attachment.vcf>