The Old Joel on Software Forum: Part 4 (of 5)

Object Persistence Layer

I have the impression that Object/Relational mapping and object persistence layers are hot topics these days.
I would like to know whether somebody here has experience with using them. What is your opinion?
I have the impression there is a trade-off between ease and speed of development (which is a lot faster with ORM) and performance (which seems to be worse). Is this true? Is it worth it?

Viking 147
Thursday, April 22, 2004

The question you have to ask yourself is: is your application complex enough to warrant using objects at all?

Once the answer is "yes" (which, I believe, happens very quickly), then you want to abstract away that database as soon as possible, and stop thinking about it. An O/R mapper is one very good way to do that. Another might be to pick up Martin Fowler's enterprise app patterns book, and build yourself a table data gateway with a domain model on top of it.

There really are many options once you've decided that you're going to need to work with complex objects instead of simple recordsets.

Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, April 22, 2004

If your application has a database it is probably worth it to have some sort of object-relational mapping tool. In the end you are going to pull that data out of the database, probably also put it into data structures, obviously a ripe area for automation. Also, working with objects is a nice decoupling from the database.

Choose an ORM tool that suits your need. A lot of frameworks are overly complex compared to what you really want to do with them. Coming from Java I would cite Entity EJBs as a particularly ugly specimen. On the other hand (still in Java) there's the hugely popular Hibernate framework which is very easy to set up and work with, and to its compliment doesn't try to abstract away the SQL query mechanism.

Personally I mostly just need to read a database table and populate an object with the column values. It took me all of a few hours to roll my own utility that matches column names with object member names and populates them automatically. Very lightweight, no mapping documents etc. needed. But a huge improvement in productivity to have an object to toss around, instead of database ResultSet (which represents an open connection to the database).

jz
Thursday, April 22, 2004

I'm currently involved in a project utilizing an O/R mapper (Mongoose Solutions' Objectz.NET, to be specific) and, frankly, it is making ALL of the difference. Here's why:

If the world were as simple as 1:1 column/field mapping, I wouldn't use it . . . but my world involves FKs and mutliple relationships; in effect, large "object graphs."

To utilize a tool that automatically traverses my "object graph" with respect to FK constraints and such is immensely useful and powerful. To be able to write a single:

PersistenceLayer.Update(Customer)

and have everything inserted or updated (in the correct order) makes "all of the difference" over handling all of this yourself.

MS is currently working on ObjectSpaces (unfrotunately delayed from VS2005), but once this hits the streets, mark my word, writing ADO and/or ADO.NET code will be considered "low level"; kin to writing assembler. ;)

Steve
Thursday, April 22, 2004

O/R mapping is fine for many things, but it's a pointless complexity and doesn't scale as well as well-architected relational systems for heavily loaded server-side applications.

(But most of us don't know what "heavily-loaded" really means, so don't worry too much unless you work at an amazon or a google.)

bah
Thursday, April 22, 2004