Hibernate vs JDBI [closed]

Question

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

Answer 1

I've used both of these. I've used Hibernate with GORM in Grails as well as in a traditional Spring app and I've used JDBI in Dropwizard.

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

1. I know exactly what SQL is going to be executed to acquire the data I'm requesting. With Hibernate, you can sometimes have to do a lot of messing around with HQL and configuring your objects to what you intended to have returned. You ultimately resort to SQL, but then have the difficultly of properly mapping your results back to your domain objects, or you give up and allow hibernate to fetch them one by one.

2. I don't need to worry about lazy/eager fetching and how that is going to affect my query time on large data sets.

3. Mappings aren't complicated because you manage them on your own and you don't have to rely on getting the right combinations of annotations and optimizations.

For your case in particular, it sounds like you'd want something lightweight because you don't have a lot of use cases and that would definitely be JDBI over Hibernate in my opinion.

Answer 2

Really, both of these solutions are just "lock-in".

If you want to go with a persisted model type interface, write your code against JPA (if you are sure it's only going to back to a relational database) or JDO (if you might want to back to relational and other-type databases, like the no-SQL movement). This is because with either of these solutions, when problems occur you can switch persistence providers without rewriting the bulk of your code.

If you want to go with a procedural persistence model (dealing with SQL queries directly and such), then go with JDBi or perhaps even JDBC. JDBi provides a very nice abstraction over JDBC; however, there are cases where you want the lower level access (for performance reasons, of the kind were you are tuning the queries and database in concert). Again JDBC is a standard such that you can swap out one database for another with some ease; however, the SQL itself won't be as easy to swap out.

To amend the SQL swap out problems, I recommend using sets of property files to hold the queries, and then a Resource loader type mechanisim to bind the SQL for the right database to the code. It isn't 100% foolproof; but it does get you a bit further.

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

Answer 3

if you have very few work upon database then use JDBI else go for Hibernate as it is very strong and provide many additional features to your persistence logic.