magpiebrain

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.
<!-more->
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.