Sam Newman's site, a Consultant at ThoughtWorks

Darren Hobbs

This is the primary reason I have mostly lost interest in tools such as Hibernate and Neo. Where the documentation says things like ‘Autogenerate your mapping layer and persist your domain objects’, I see ‘Tightly couple your code to your database’.

Which I don’t think really follows. Firstly, if you’re in the envious position of being able to have complete control over your schema, I don’t see why generating a schema from your domain objects is a problem, as long as your domain objects don’t become polluted by the underlying persistence mechanism. It’s not the tools fault if you end up with this tight coupling – it’s the fault of your architecture.
Lets look at my current project. We’re using JDO for persistence, but that’s a trivial implementational detail. Our domain objects exist in their own layer, and are completely clean POJO’s. All persistence is performed by a repository layer. Currently we’re using our JDO providers mapping tool to create our Object->Schema mapping tool – our mapping tool is also capable of generating a schema based on the mapping file.

Relational databases are hard to change. Especially once they’ve gone live. They very quickly foster an ecosystem of reports and queries, and almost always become an ad-hoc integration point for several applications, making schema changes very difficult.

There will come a time when we’ll lose control over our schema – this may happen after our first release (when we’ll have historical data that will need to be migrated) but in all likelihood we’ll fix our schema once our DBA has given it the all clear. At that point we’ll stop using the domain object to create the schema – it’s a pain, but a necessary evil. But with the right structure of your code and a decent build, I can’t see why your code ends up tightly coupled to your database.

Here is a case in point. We’ve found out that for strategic reasons we need to change over to Hibernate (personally I prefer JDO). The impact on our code? A single new implementation of our primary store (that’s one single class) – the real work is in rolling all the hibernate bindings, and even then it’s a one-time cost.

4 Responses to “In defence of object-relational mapping tools”

  1. Jeff Brekke

    I agree, we should encapsulate the ORM layer, or we are tied to the ORM framework. I guess Darren talks about coupling to the database, but I agree with you the quote should end with “… to the ORM framework.”

    We’ve not done this well at my work, we’ve chosen the path of pain. Mostly unknowingly, but we can’t seem to break out if it…

  2. Sam Newman

    I’ve certainly worked on projects where things were sub-optimal – I might actually write up what we’ve been doing in more detail, as that’s often a good way to get some feedback…when you do something you haven’t done before you’re always worreid you’re doing something completely bonehead šŸ™‚

  3. Ian Lim

    Hmm… something like Spring DAO framework would be useful in encapsulating against the various ORM layer

  4. Sam Newman

    I’m sure it would. You can have encapsulation of the ORM layer without it of course, using simple, clean, Java code. This does have the (dis)advantage of not using XML of course, but I happen to prefer writing Java to XML…


Leave a Reply

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

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

Facebook photo

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

Connecting to %s

Basic HTML is allowed. Your email address will not be published.

Subscribe to this comment feed via RSS

%d bloggers like this: