Why all Object/Relational Mappers can’t cut it

Mats Helander makes a statement that links domain model and O/R mapping.

In my opinion, that statement only sounds revolutionary if it would mean: If you’re not using <my favorite ORM> you’re not using a domain model.

But I don’t think it does. It means, if my objects are to have state persisted in a relational database, I’m about to do O/R mapping.

But whether I need an ORM or not, does not depend on whether I have a domain model or not. It depends on my object paradigm.

If I think objects are cohesive data structures with some functions, well then any ORM might free me from the chores of writing database access. The less visible, the better. Maybe a JDO derivative like OpenAccess will do.

If I think objects are responsibilities, then it’s actually harder to find any generic approach for persisting my object’s state.

But it could be worthwhile thinking through why Microsoft is postponing ObjectSpaces and WinFS.

Myself, I had to dismiss lots of ORMs because they all couldn’t cut it for my colleagues requirements.
Even with OPath or other sophisticated query languages, ORMs just aren’t sustainable bridges across the impedance mismatch. We’re not doing rocket science, but an ORM should not put the RDBMS on a leash. If I’d want that, I’d go with Caché.

I wait for the light at the end of the O/R tunnel. Whenever there is an ORM that goes beyond persistence and also maps significant classes of stored procedures, please let me know.

Advertisements
This entry was posted in Best practices. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s