Why ORM?

[Robert Stackhouse]

I've been puzzling this one out lately. Other than the fact that as a programmer I really, really hate SQL, I'm not sure I know of a single convincing reason as to why to use O/R Map-pers/ing in code. 

I would like to argue that ORM makes me more efficient as a programmer, but I'm not really sure I can do that. Updating NHibernate mapping files has been at times extremely painful for me and even more so for more junior developers to the point where one of them I was working with on project went the other way round and generated the objects from the DB schema using SubSonic (this just feels dirty to me).

I'm not particularly crazy about the Active Record pattern either.

I'm trying to put my finger on the problem that ORM solves, and right now—maybe owing to lack of sleep—I'm not able to do that.

To sum up, why ORM?

--
Robert Stackhouse

http://robertstackhouse.com/flavorsof
http://agilebcs.org
http://bcsbloggers.org
http://uweb.tamu.edu

[Mike Abney]

Do we need a reason other than we really, really hate SQL? :-)

A lot of the benefits of ORM frameworks come from the fact that they tend to do a bit more than *just* mapping objects to tables. Some examples:

• They handle caching so that the app doesn't load the same stuff from the DB multiple times unnecessarily.
• They make it harder (though not impossible) to write badly-performing SQL for simple queries.
• They use proper DB connection pooling to enable higher throughput.
• They integrate with transaction-handling mechanisms, including support for appropriate locking mechanisms.
• They are portable between DB versions and types. That is, the same code/mappings can be used for Oracle 9i and 10. They can also be used for MySQL, DB2, SQL Server, Postgres, etc.

That's off the top of my head.

While there are separate libraries/frameworks for many of those things, it is really nice to be able to have all that *plus* be mostly SQL-free.

Mike Abney

http://practicallyagile.com

http://agilebcs.org

http://improvingpodcasts.com

--
You received this message because you are subscribed to the Google Groups "CodeDojoBCS" group.
To post to this group, send email to coded...@googlegroups.com.
To unsubscribe from this group, send email to codedojobcs...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/codedojobcs?hl=en.

[Robert Stackhouse]

True, they do eliminate a lot of headaches that come from dealing with SQL. Mike, all those points you listed seem to address design from a systems integration level. I'm more interested in what specifically does an O/R mapper like NHibernate offer over other approaches to persistence like active record, document databases, or just plain old ODBC from an application design viewpoint.

One of the hidden costs of using O/R mappers is sometimes you encounter "weird" behavior when you are trying to do meta programming or other off-the-beaten-path programming chores.

Doctrine (v 1.2 anyway) can make testing your domain classes damn interesting.

I think what I'd like to arrive at is a chart comparing features/side-effects of one persistence method to the others.

Robert

[Kyle Marshall]

One of the best features I think ORMs have is the ability to only
update what has been changed at the end of a transaction. Without this
feature, you typically have to tell the Data Layer what has changed
explicitly or save back everything which can be a little too
unforgiving without concurrency control.

-Kyle