Credera’s Hibernate Bantering – A view from experience with ORM

Within Credera, our technology and strategy leaders often engage in emailing or slacking around the latest content or position on a given piece of technology. These sometimes come from client questions or projects and the ensuing discussion generally leads to a consensus and position on where that technology has strengths/weaknesses and ultimately helps us refine how, when, and why to leverage that tech.

This week’s discussion was generated off of a Java Zone presentation by Christin Gorman entitled “Hibernate should be to programmers what cake mixes are to bakers: beneath their dignity.” For those unfamiliar:

With a view into this topic, I thought it would be helpful to share the thoughts from some of our technology leaders about why you should or shouldn’t care for Hibernate.

Jason Goth, Principal Architect, Technical Architecture & Strategy Practice

My answer… use native JDBC, Stored Procedures, JPA, some ActiveRecord implementation, iBatis, Hibernate, or whatever else makes sense. I’ve used all to great success and all to terrible disaster. They all have their time and place. We should understand the pros/cons of each and pick the right one. I’m just against using Hibernate by rote because it’s “best practice.”

But, this is not strictly a Hibernate discussion. The more interesting discussion is what Christin call out in her video:

I agree. Often people use these frameworks to allow developers to continue working ignorant of core database concepts (e.g. table structure, SQL, query optimization, locking in various storage engines, etc.) This is a bad idea. Taking developers evenfarther away from the data, in my experience, causes an increase in the number of issues, not a decrease. The answer to me is to teach developers these core database concepts so they can make intelligent decisions on the correct data access methods (e.g. ORM, JDBC, etc.)

I’m also a big believer that data outlives applications. It’s not uncommon to have round 3 of the application going against the round 1 data source. Learning common “RDBMS patterns” is as important as “code patterns”. Understanding existing data structure and database operation makes better developers because it uncovers a whole host of domain concerns we might not otherwise find out about.

Micah Blalock, Senior Architect, Integration & Data Services

Loved this talk. But, full confession, I like Hibernate, a lot.

If I’m working on a simple CRUD application, I’ll use Hibernate (or Spring Data) every time. I don’t know any programmer who considers CRUD-level SQL or ORM mapping to be the creative, enjoyable part of any project. Hibernate is also one of the more open ORMs, allowing you to drop into native SQL where it’s necessary. (Side note: I don’t care for the JPA/hibernate annotations, always thought the xml config was simpler to read and understand.)

I think there is a larger point here that I agree with wholeheartedly, frameworks are eating the IT world. We’re using more and more multipurpose tools and frameworks that are too large and opaque for anyone to fully understand.

After reading Martin Fowler’s article ORMHate, I’m interested in exploring NoSQL as a more generalized solution the ORM problem, but without all the poorly written SQL.

Dustin Talk, Senior Architect, Technical Architecture & Strategy Practice

In general, I agree with Martin Fowler on OrmHate… and I’d love to go without Hibernate, but my reality has always been that it’s a necessary evil…. like taxes. Understanding databases (what is a normalized table, why indices are important, when a temp table is created, how locking works in various storage engines) is not something that junior resources are always trained on. If this pattern is adopted, it is vital to ensure that both client resources and internal junior resources are brought up to speed on best practices in database design and optimization.

When I have seen deviations from this, interesting things have happened such as: someone who had all production orders temporarily deleted (Circa 2011), consistent deadlocks on production schemas and small outages from self-induced queries (Circa 2013), a potential for a information leakage (Circa 2015). I mention these to show the criticality of database and sql awareness we all must value; granted these can exist even with ORM.

One additional mention is that with Hibernate you may bypass being locked into a specific SQL grammar / version constraints. Ex: MySQL != TSQL != PostgreSQL; “rename schema” works in one version of MySQL but not others. The layer of abstraction that Hibernate and other ORM solutions provide gives some value in that you are not tied to a single relational technology.

Having said that, there have been a number of times where it made absolute sense to not use Hibernate / ORM.

Did these perspectives differ from yours? If not, or if so, let us know below. We are always ready to talk tech or hear the latest sports opinion on a given technology.

——

About: Dustin Talk is a Senior Architect at Credera. He enjoys discussing technology perspective and strategy, running projects with agility, implementing application integrity, and understanding how technology can deliver business value. Read more about Credera’s perspective here.

• Hibernate Bantering
• ORM