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
$table=$db->{my_table}
$row=$table->fetch($id);
$row->{count_value}=77;
$row->update();
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.
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
