Encapsulate the Database

Picking up the ‘schema as 3rd party code’ idea, I want my database access to be encapsulated behind an insulation layer that decouples the business logic from the table schema.

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’.

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.

For this reason alone, any tool which works by coupling business logic to to the database causes me concern. On almost every project I’ve seen that had an OO application and a relational DB, the persistence mechanism became a point of pain. Code becomes really hard to change because its constrained by the database schema and there’s usually an additional maintenance burden of keeping an XML configuration file in sync.

Advertisements