ORM you say?

I had a fun chat with some of the guys and girls of the London Java Community (LJC) this week.

There were a few of the usual war stories - like the guy who was talked into going along to a job interview and found that the company had a very zealous approach to "not invented here" technologies - to the extent that they had actually produced their own source control system.

Not embracing open source is one thing, but reinventing the wheel is another extreme (unless you happen to be Linus Torvalds).

A few pints of Magners into the evening, discussion turned to a recent blog post by someone who was calling out ORM as an anti-pattern.

During my first year in London I took the time to read Java Persistence with Hibernate.  It gave me a greater appreciation for what Hibernate was capable of, and an understanding of how easy it could be to generate poorly performing data access (such as the infamous N+1 queries).

When it came time for me to wear the "Technical Team Lead" hat on an e-commerce project, I learned the hard way what effect a seemingly trivial design decision could have.  At the time the Hybris e-commerce platform included a proprietary xml format for producing Java classes representing persistable objects.  The way that the objects can relate to each other could result in database table structures that were not SQL friendly - which made the search engine indexing less useful.

It's my strongly held belief that no matter how good your ORM system is, there will always be a time when someone has to pull out alter table and friends to refactor.


NB: NoSQL systems have not been considered in any of the above statements.