DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations

Trending

  • Avoiding Pitfalls With Java Optional: Common Mistakes and How To Fix Them [Video]
  • An Overview of Kubernetes Security Projects at KubeCon Europe 2023
  • Working on an Unfamiliar Codebase
  • Logging Best Practices Revisited [Video]
  1. DZone
  2. Data Engineering
  3. Databases
  4. Thoughts on Hibernate

Thoughts on Hibernate

Mahboob Hussain user avatar by
Mahboob Hussain
CORE ·
Aug. 26, 14 · Interview
Like (1)
Save
Tweet
Share
13.39K Views

Join the DZone community and get the full member experience.

Join For Free

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

Database Relational database Hibernate application sql Software development

Opinions expressed by DZone contributors are their own.

Trending

  • Avoiding Pitfalls With Java Optional: Common Mistakes and How To Fix Them [Video]
  • An Overview of Kubernetes Security Projects at KubeCon Europe 2023
  • Working on an Unfamiliar Codebase
  • Logging Best Practices Revisited [Video]

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: