I followed Hibernate ORM to hell and came back alive to tell about it

The title might have hinted you that I'm going to diss ORMs and preach against using them at all cost. Well, that's correct for some cases, as it depends what are you trying to accomplish in your project.

The reason I wrote this article is because I just think people are misusing ORMs like Hibernate for any kind of project and any kind of data modeling requirement, without considering the actual pros and cons and the consequences of their choice.

In this article I would try to avoid listing the pros and cons of using an ORM, as there are many of these articles out there (so you can Google it). My approach to this matter will be to guide you to which questions you should ask yourself when choosing whether to use an ORM in your next project or not.

In the article, I'll use Hibernate as an example for an ORM framework, but the same questions are relevant for other common ORM frameworks such as: Entity Framework, nHibernate, Django, DataMapper, CakePHP, Dapper, ADOdb, Axon ORM.

Question 1 - Is your data model static or dynamic?

Looking at the meaning of ORM (Object Relational Mapping), you probably already get a hint on the fact that ORMs are built for static data models, as they are using data mappings.

If your project requires a configurable data model stored in a relational database (such as MySQL), I advise you not to use ORM and look into other alternatives (In my opinion, writing SQL queries yourself can never be bad if you learn about it and do it right).

Question 2 - What's your project's main use case?

If 95% of your project's goal is achieved using simple CRUD (Create, Read, Update, Delete) operations, ORMs like Hibernate are your golden choice. They usually create very easy and optimized queries for such operations, and writing those operation will be a piece of cake using their libraries.

If that's not the case and you need other more complex functionalities in your system, ORMs might not be a good fit. How do I define "complex functionality"? Well, imagine how the queries of your main use cases look like - if the answer for a significant portion of that is complex / reporting / analytics queries, I wouldn't recommend going down the ORM path.

Question 3 - Are you using complex stored procedures?

If you're using / wrote some complex stored procedures as part of your project's logic, ORM might not be a good fit for you. ORMs usually fall short when things get too complicated (as they are working best with CRUD operations). If you have many of those stored procedures / complex queries with subselects or recursive queries, I would think twice whether to use ORM, at least for those use cases.

Question 4 - Are you using database-specific functionality?

ORMs are built for generality. That means that every time you go into the "customized" area, you'll fall short with ORM. If you are using keywords / functions / procedures which are unique to your database of choice, you might end up tweaking the system just to make things work and end up working a lot more than just implementing it yourself without ORM. If your project will require a lot of this custom database work to be done (instead of using plain common SQL), please re-consider.

Summary

So to summarize, from my experience (and I'm sure some might disagree), ORMs are AMAZING for projects that are very CRUD oriented. For projects which hold complex queries and functionality within them, I would suggest using plain SQL and master it.

If you insist (and it might be correct) to use an ORM even when some of the above questions lead you to do otherwise, I think you should consider to mix and match the ORM framework with another framework that will allow you to take care of those complex queries - for example, JOOQ for Java.

If you are a programmer looking to decide whether to use ORM, my goal in this article was to save you the meeting with the DBA, where he tells you that you "need to take out this complex query out of Hibernate (or any other ORM) to optimize it and get 500% improvement in performance".

One thought on “I followed Hibernate ORM to hell and came back alive to tell about it

  1. There is no Silver Bullet! That's the reason why High-Performance Java Persistence ( https://leanpub.com/high-performance-java-persistence/ ) has three parts:

    - JDBC
    - Hibernate
    - jOOQ

    1. Is your data model static or dynamic? This is not about Hibernate, but about RDBMS in general. However, you can achieve a certain level of dynamic schema modeling using JSON which can also be mapped as a Hibernate type.

    https://vladmihalcea.com/2016/06/20/how-to-map-json-objects-using-generic-hibernate-types/

    2. What’s your project’s main use case? Hibernate is designed for OLTP. The User Guide clearly states that. However, there is a very good reason why Hibernate and JPA allow you to run any native SQL query:

    https://vladmihalcea.com/2017/01/18/the-jpa-entitymanager-createnativequery-is-a-magic-wand/

    3. Are you using complex stored procedures? That's where jOOQ shines. It's the best way to access a stored procedure or database function from Java. 100% agree with you on that.

    https://leanpub.com/high-performance-java-persistence/read#leanpub-auto-stored-procedures-and-functions

    4. Are you using database-specific functionality? Again, Hibernate does not prevent you from using database-specific functionality. You don't have to use JPQL for everything. That's an Anti-Pattern.

    JPQL is only useful for fetching entities that you plan to modify:

    https://vladmihalcea.com/2016/09/13/the-best-way-to-handle-the-lazyinitializationexception/

    Native SQL is suitable for everything else. Otherwise, why do you think Hibernate comes with a ResultTransformer:

    https://vladmihalcea.com/2017/04/03/why-you-should-use-the-hibernate-resulttransformer-to-customize-result-set-mappings/

Comments are closed.