Hibernate vs JDBI

Question

I am creating a web service using the Dropwizard infrastructure (version 0.7.0). It involves executing some read-only queries in a database, managing a result set, and then returning that data set. I use MySQL as a database engine. Since I am new to this structure, I want to know which option I should choose: Hibernate or JDBI.

Answer 1

I used both of them. I used Hibernate with GORM in Grails, as well as in a traditional Spring application, and I used JDBI in Dropwizard.

I really enjoyed the simplicity of JDBI, and here are a few reasons why I prefer it over Hibernate.

• I know exactly what SQL will be executed to get the data that I request. With Hibernate, you sometimes have to talk a lot with HQL and tune objects to what you want to return. You ultimately resort to SQL, but then it’s hard for you to correctly display the results on the objects of your domain, or you refuse hibernate and select them one by one.

• I don't need to worry about lazy / impatient extraction and how this will affect my query time on large datasets.

• Mappings are not complicated because you manage them yourself and you don’t need to rely on getting the right combinations of annotations and optimizations.

For your case, in particular, it looks like you need something lightweight, because you don't have many use cases, and in my opinion it will be JDBI over Hibernate.

Answer 2

Indeed, both of these decisions are simply "blocked."

If you want to use an interface with a saved model type, write your code against JPA (if you are sure that it will return only to the relational database) or JDO (if you want to return to relational and other types of database, such as movement without SQL) . This is because with any of these solutions, if you encounter problems, you can switch persistence providers without rewriting the bulk of your code.

If you want to go with a procedural persistence model (directly related to SQL queries, etc.), go to JDBi or maybe even JDBC. JDBi provides a very good abstraction over JDBC; however, there are times when you want to access at a lower level (for performance reasons, for example, you set up queries and the database at a concert). Again, JDBC is a standard that makes it easy to swap one database for another; however, SQL itself will not be easy to replace.

To change the problems with replacing SQL, I recommend using a set of property files to store queries, and then a mechanisim resource loader type to bind SQL for the correct code database. It is not 100% reliable; but he is a little more than you.

Now, if you ask me what I will use, I highly recommend JDO.

Answer 3

if you have very little work with the database, then use JDBI, go to Hibernate, as it is very powerful and provides many additional functions for your save logic.