[nycphp-talk] Never heard that term: Viet Nam of programming
paul at devonianfarm.com
Wed Jan 24 20:26:42 EST 2007
Hans C. Kaspersetz wrote:
> ORM is a beautiful thing. We are using ORM extensively on a large
> financial application and it works absolute wonders. It has made many
> non trivial tasks, especially those that involving very complex
> objects that span many tables, very manageable. I was not a believer
> at first, I thought it was complex and unpredictable. I wasn't sure
> what I was going to get back from it at any given time. However, with
> refinement and practice our ORM system is very predictable and saves
> tons of time. It can be done, it just takes time to develop. I have
> a debut of gratitude to Andrew Yochum and Chris Hendry. They did a
> fantastic job implementing it.
Is this a system you've built in-house?
I've certainly seen places where ORM was as much of a problem as it
was a solution. On the other hand, I've done more than my share of
maintainance on applications where sql code is distributed throughout
the application, and (worse) applications where people developed a
database layer which encapsulated bad practices and bad assumptions
about the problem domain.
One basic trouble with ORM is that it violates the principle of
"don't repeat yourself;" you have to maintain a database schema ~and~
an object hiearchy. Change one, and you have to change the other.
Another problem is that there is a semantic mismatch between objects and
sql -- there are three ways to represent inheritance relations in sql,
and all three are unsatisfactory in some way.
I've been working lately with a minimalist "active record" that
introspects the database, and lets you write something like
it saves a lot of fumbling with 'addslashes' or '?' parameters,
thus eliminating a common kind of repetitive coding. It doesn't try to
map database 'rows' to anything else, but it can still automate certain
aspects, such as timestamping changes to rows, and keeping an archive
of who changed what when. I've been trying to develop something that
does 20% of the work and eliminates 80% of the pain of writing "plain
old" applications with lots of SQL. So far the system is
zero-configuration, although I'm sure I'll add features to it someday
that require some configuration -- for instance, I do see an easy way
to implement a certain kind of inheritance.
ORM systems do get interesting, however, in architectures that
really take advantage of the objects. For instance, if you can design
your objects so that aspects cut across them, you can build really
powerful systems quick.
More information about the talk