11

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.

th3morg
  • 4,321
  • 1
  • 32
  • 45
rigal
  • 522
  • 1
  • 6
  • 19

3 Answers3

25

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.

th3morg
  • 4,321
  • 1
  • 32
  • 45
4

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.

Edwin Buck
  • 69,361
  • 7
  • 100
  • 138
  • "Switching persistence providers without rewriting most of the code" is a bit... too optimistic. For a not trivial project, changing the JPA-provider would be a challenge. I've been involved in such a project in the past (Hibernate -> EclipseLink), and it turned out to be much harder than expected. (it was a pure JPA-based application!). And if your application uses some extensions (like hibernate-envers) that have no JPA alternative... – Gmugra May 21 '21 at 11:24
  • @Gmugra If you keep very tight controls on only using ANSI SQL (which nearly nobody constrains themselves to) you can switch quite easily. Problem is that people eventually put in server specific extensions to SQL or DML commands which aren't portable. The bonus with JDO is that the JDO stack will write your SQL to match the server, if you go about it that way. – Edwin Buck May 21 '21 at 15:59
  • With trivial application, that only needs trivial SQL, you will be fine indeed. (But why to use huge ORM for trivial app?) But any, even relatively simple, steps left and right will lead to possible problems. e.g. we've gotten a lot of problems with relatively simple JPQL queries that work fine with Hibernate, but require modification for EclipseLink (often a silly modification). Also, the JPA specification is not always 100% unambiguous. In some situations, providers may go different ways, and those ways will be fine according to the specification, but not compatible with each other. – Gmugra May 26 '21 at 07:54
  • @Gmugra As I said before, you can always go JDO. No SQL, no silly need to modify SQL. – Edwin Buck May 26 '21 at 17:03
2

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.

kartikag01
  • 1,539
  • 1
  • 18
  • 36