ken at secdat.com
Fri Jan 26 21:15:13 EST 2007
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.
> 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?
> Were they conscious or unconscious compromises?
I can't tell you about the unconscious ones :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 261 bytes
Desc: not available
More information about the talk