Big Data/Analytics Zone is brought to you in partnership with:

Mahboob has posted 1 posts at DZone. View Full User Profile

Thoughts on Hibernate

08.26.2014
| 10151 views |
  • submit to reddit

The main purpose of Hibernate/JPA was to address and solve the Object - Relational impedance problem. Java is an object-oriented language and there is no way but to use classes and methods. So we design and develop our Java applications in the object-oriented way.

Since programmers use and deal with objects, and data resides in tables related by common fields (keys), there is a mismatch. Technically, yes, the way data are laid out in the columns of tables and the way they are used in the application as the class / instance variables there is. So when we see, comprehend and discuss the data on the application side and the database side, there is a difference in the visualization and communication.

However, this mismatch or "impedance" does not come in the way of software development that it requires a framework that abstracts away all the database-related code. It is not rocket science that programmers can't work with rectangularly laid out data. In my opinion application programmers have, and will continue to have fluency, with both classes and tables.

Database concepts and commands are part of the learning curriculum of any software-related course. Engineering / computer science students are taught basic SQL syntax and know how to query databases. So, in a typical case you would NOT have a developer who says that they know only an object-oriented language and will work only with it.

I have seen two more behaviours. When asked to do a design, people invariably end up thinking in terms of rectangularly-laid out relational data. Some how operations and data seem to come comfortably to a lot of people. Thinking only in terms of objects and their relationships seems to come secondary. Even if they start with classes, after some time, the thought process and vocabulary settle around methods and tables.

The second aspect comes with supporting production problems. As programmers gain experience and move into senior roles, they are called into fix urgent problems faced by customers in live environments. The first steps almost always include looking at log files and the database. A lot of analysis centers around database tables and columns to understand the values or the state of the data.

Part of this comes from the fact that the customer-support guys are chasing development teams over emails and phone, some times even standing behind their back, so trying to debug through source code is not done every time as it takes a little bit more time to set up. Dealing with the log file exceptions, database values and Googling around gives quick fixes in a lot of cases.

Thus a programmer gets imbibed with relational structures thoroughly. When the production-support developers become the designers for the next release or the next module, they quickly get into the methods - tables thought process and vocabulary. The so-called object-relational impedance, even if it were existing previously, just disappears over time.

Hence the very premise, the insurmountable object-relational impedance, that led to building ORM frameworks is questionable. That's not the only problem. There started a new set of issues as Hibernate/JPA evolved.

People had to learn a new framework. The very idea of learning another framework seemed to be an additional responsibility, kind of a burden. It involved new APIs, first XML then annotations, and new configurations. In comparison, JDBC just seemed to be a natural part of Java with just seven steps to learn.

From my experience, I recall that Hibernate-based applications consume more hardware resources. In the era of hardware commoditization and 64-bit systems, this is normally not a problem. There are performance problems related to using Hibernate.

Of course, by using performance-improving techniques, we could address them. But then this meant spending time on learning those things, adding Hiberanate/JPa as a training topic for freshers, applying the performance-improving tips as an extra activity and retaining that knowledge within the groups. In the pre-ORM days, if application queries were taking a lot of time, you just moved some action to database procedures.

A lot of business operations and reports involve writing complex queries. Writing them in terms of objects and maintaining them seems to be difficult; it is easier to read and comprehend complex queries in terms of tables. In such cases, people prefer to write native SQL queries just overriding the persistence framework.

This is not to say that there is nothing good at all in Hibernate/JPA. The current thinking around Hibernate seems to be : if your application is primarily a CRUD-drive one, performance is not that critical, and as a development team you have a good say in the database design, you could just go for Hibernate/JPA. It would help achieve your goals in fewer lines of code than JDBC.

There are other benefits too. Lazy initialization patterns are already available in Hibernate, and they are not easy to hand code. Intelligent updates where only the updated fields are included in the SQL reduce network traffic. Since Hibernate is coming up with polyglot persistence, it would be easy to migrate to a NO-SQL database.

Considering the trade-offs, I would think that over a period of time, the development world will move away from Hibernate/JPA. At the moment, there are alternatives in the form of Spring JDBC and jOOQ, amongst others. I have looked at jOOQ briefly.

It reverse-engineers the tables to create java mapping classes and allows you to query the objects in an almost SQL like manner. The generated classes have the same name as the tables, so your Java code "reads" like SQL. I like it.

From the aspects of reducing the learning curve due to decreased boilerplate and annotations, and communicating via table names and SQL queries, jOOQ looks promising. It needs to be explored a bit more by developers. Figure out if it is tackling the unnecessary object - relational impedance problem or unnecessary boiler plate code. If it is just the latter case, then it's in proper direction.

(Views are completely personal, I don't have any business interests with the makers of the frameworks mentioned in this article).

Published at DZone with permission of its author, Mahboob Hussain.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Fabien Bergeret replied on Tue, 2014/08/26 - 3:20am

I don't understand your first point: "So we design and develop our Java applications in the object-oriented way."

Working in an object oriented way should be a higher choice thant choosing Java. Then, when OO approach is chosen, you can chose the implementation language.

But chosing Java first is putting the cart before the horse.

Lukas Eder replied on Tue, 2014/08/26 - 7:03am

From the aspects of reducing the learning curve due to decreased boilerplate and annotations, and communicating via table names and SQL queries, jOOQ looks promising. It needs to be explored a bit more by developers. Figure out if it is tackling the unnecessary object - relational impedance problem or unnecessary boiler plate code. If it is just the latter case, then it's in proper direction.

Great to see that the decreased learning curve and boilerplate is recognised as such by a new jOOQ user. These are some of the main ideas behind the jOOQ API. If we could, we'd even go further and implement true embedded SQL in Java, along the lines of SQLJ. Unfortunately, as of Java 8, there is not yet any such language plugin mechanism to natively enhance the compiler.

jOOQ is not tackling the "object - relational impedance problem." It is just a type safe replacement for JDBC, mainly targeted at those who really want to write SQL in their applications, and who really want to operate on relational entities (e.g. tables, or denormalised results), rather than on object-oriented domains. In other words, an early application design choice is: "Should I use an ORM (e.g. Hibernate)? Or should I use SQL (e.g. JDBC or jOOQ)? Or both?"

The main differences between the relational-model-centric and domain-model-centric approaches is outlined here.

Very interesting thoughts about people being more comfortable with tables, btw!

Joseph Ottinger replied on Tue, 2014/08/26 - 7:45am

Considering the trade-offs, I would think that over a period of time, the development world will move away from Hibernate/JPA.
I don't think many people will try to debate the points that say "Hibernate has a difficult problem to solve" or that "Hibernate struggles in some areas." There's no issue with any of that, because it's true (and obviously so).

However... for better or for worse (better, IMO), the world is *not* moving away from Hibernate and/or JPA, but is instead continuing to move *to* them.

The growing NoSQL movement is great - and wants different APIs - but the best of them end up looking like MongoDB (with a JSON-like layer) or Hibernate/JPA. If the world were going to move away from ORM, it'd have done so a while back, IMO.

Aleksey Novik replied on Tue, 2014/08/26 - 10:11am

Very well said, I think Hibernate is mostly meant for applications that are written according to the Domain Driven Design  approach, where the whole program is written around the notion of a Domain Model . 

The Domain Model is a set of Java classes that represent business concepts in an object oriented way. Hibernate is meant to make it as painless as possible to map from a domain model to database tables back and forth.

Hibernate  is meant to as tranparently as possible to synchronize a graph of objects in memory with a set of database tables.  These problems are hard to get right, and have famously earned the building of ORMs  to be the Vietnam of Computer Science.

Usually DDD == Hibernate in the Java world, as it's by far the most used ORM.

To consider using Hibernate in a project, a good starting point is to ask if the program needs a Domain Model, and if it will be build the DDD way. If so, an ORM (like Hibernate) seems essential, otherwise a relational view of the data can be perfectly valid.

DDD is only advised to be used if the problem has a minimal degree of complexity, but  enterprise software development industry seems to have converged around DDD because most often applications do have that minimum level of complexity.

Hibernate can also be used in combination with native queries and only as a mapping and synchronizing mechanism between OO and the DB, but by some reason this use is not very frequent.

It can even be used to map everything to only an hierarchy of Java Maps, but that use is even less frequent, the sweet spot of Hibernate is really DDD. 

Mahboob Hussain replied on Wed, 2014/08/27 - 12:17pm in response to: Fabien Bergeret

Agreed.

What I have seen is that once Java is chosen to develop applications, and the organization has quite a few Java developers, it becomes a Java shop. The language is already chosen. I just wanted to convey was that you can't be anything but object-oriented because of the language.

I think I could have worded the leading paragraph better.

Mahboob Hussain replied on Fri, 2014/08/29 - 6:03am in response to: Lukas Eder

Thanks, Lukas for clarifying. Maybe it's just my experience but the relational choice seems to be coming naturally for development teams. If you can keep the learning curve small as the framework evolves, it will be good for adoption. All said and done, there are two (main) concepts on the database side : primary - foreign key relationship and join tables. JDBC has only about six or seven steps to code. We shouldn't be needing a 900 page book to learn a new framework.

Joseph Ottinger replied on Fri, 2014/08/29 - 6:54am in response to: Mahboob Hussain

I don't think you need a 900 page book to learn a framework - the 90/10 rule applies for ORM just like it does for most things. For better or for worse, most of Hibernate is really simple; you need to understand object models, and you need to master the idea of objects' managed state (when and how); that's just part of understanding that the relational access isn't something YOU are doing (or have to do). 

JDBC is analagous to Hibernate; you'd have six steps with JDBC (get connection, build SQL, populate data, execute, commit, close connection) and Hibernate (get session, start transaction, build object or query, populate object or query, interact, commit, close session -- with some of the steps folding together).

People *do* understand tables. They also, since they're using Java, understand objects. Normally they can see the impedance mismatch - and that's just a factor of the domain - the fact that they're programming, not the model. If you're not using Prevayler or some other object store that persists everything as a single state, you're going to run into things where the modeling solution isn't perfect.

Lukas Eder replied on Fri, 2014/08/29 - 7:35am in response to: Mahboob Hussain

Hmm, I wouldn't be limiting SQL to relationships and joins. One of SQL's killer feature is its (hidden) composability through all sorts of constructing table references, such as derived tables, collection tables, table-valued functions, correlated subqueries, and of course joined tables.

Would be interesting to hear more feedback from you. We certainly don't want a 900 page book as a prerequisite to learn jOOQ - although there are a lot of nice-to-have features such as converters, SQL transformation capabilities for row-level security, multi-tenancy, etc. that will certainly need some documentation, and that are completely lacking in JDBC.

Mahboob Hussain replied on Mon, 2014/09/01 - 6:32am in response to: Joseph Ottinger

 If you are referring to O-R impedance, my opinion is that it is not a problem or a problem that need not be solved through an ORM.

Developers are not going to stop using Hibernate or will not get rid of Hibernate in existing applications. My thought was that the number of database access frameworks other than Hibernate/JPA will increase.  That's what I meant when I wrote 'the development world will move away from Hibernate/JPA.'  The sentence perhaps didn't come out the way I was thinking.

Jaime Metcher replied on Wed, 2014/09/03 - 4:35pm

 I agree that Hibernate is most useful with a DDD approach.  If you have a high value domain model, then protecting it from cross-cutting concerns like ORM is very valuable.  And unless you're just writing procedural code in Java, you are doing ORM, whether you use a framework for it or not.

I completely disagree that Hibernate is indicated for basic CRUD applications.   This is query generation, not ORM, and as you point out there are simpler solutions for that. If you're already using Hibernate, then sure, why not, but this is not where Hibernate's real value is.

Mahboob Hussain replied on Mon, 2014/09/29 - 2:28pm in response to: Aleksey Novik

 Thanks, Aleksey. And also for the Vietnam of Computer Science links. Gave me a lot of details of the O-R problem, which of course, I don't agree is a problem at all.

Coming to the present: I suspect that a lot of Java application teams that are using Hibernate wouldn't have made the Hibernate choice after having a good DDD. Sometimes they may not be even aware of DDD. But if we ask them, they would say Yes, to : Do you have a set of domain classes? Do you have entities and value objects? Do you have aggregations? Do you have services? Do you follow design patterns like Factory?

But then, if we ask: Are you using DDD? Answer: Not sure. Have you read Eric Evans book? Ans: No.

So, I think such projects suffer from not having a proper DDD, and get along with having an accidental and partial DDD. Many teams go with Hibernate because their applications become portable across databases without much effort. This gives the marketing guys some talking points.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.