JavaVersionManager VS JDBI

👉 Explorez JavaVersionManager sur GitHub : https://github.com/Jachou-yt/JavaVersionManager

Directly using the JDBC API in your application code is low-level and verbose. That's why libraries like Jdbi, Spring JDBC Template and Sql2o exist. They provide: named parameters, row mapping, pluggable data type binders/ row mappers/ JSON mappers.

Suppose we're developing an application that allows speakers to submit their talks to a conference (for simplicity, we'll only record the talk's title). Following the Transaction Script pattern, the method for submitting a talk might look like this (using JDBI for SQL):

_relational_ is the key word you're missing.

ORMs map _objects_ to _relations_ (i.e. tables).

"Unlike ORM frameworks, MyBatis does not map Java objects to database tables but Java methods to SQL statements." https://en.wikipedia.org/wiki/MyBatis

"Jdbi is not an ORM. It is a convenience library to make Java database operations simpler and more pleasant to program than raw JDBC." https://jdbi.org/

"While jOOQ is not a full fledged ORM (as in an object graph persistence framework), there is still some convenience available to avoid hand-writing boring SQL for every day CRUD. That's the UpdatableRecord API [which is only one part of it and you don't have to use it]" https://blog.jooq.org/how-to-use-jooqs-updatablerecord-for-c...

While this may work for greenfield applications, I don't see this working well for preexisting schemas. From their getting started page: "Database fields are automatically created for any abstract getter methods", which definitely scares me away since they seem to be relying on automatic field type conversions.

I prefer to manage my schemas when I can and do type and DAO conversions via mapper classes in the very simple and elegant JDBI framework where you write SQL annotations above your DAO methods https://jdbi.org/#_declarative_api

JDBI does wonders for wonky old schemas you've inherited, since joins etc work out of the box (just throw them in your annotations!) The annotations can also link to .SQL files for the big hairy queries.

All these "do magic" frameworks (hibernate being one of the first) work in the simple cases but then fall apart whenever you need to do anything complex/not-prescribed. I end up having to dig into the internals of the framework to see what's going wrong which negates their whole value add.

I found JDBi[1] to be a really nice balance between ORM and raw SQL. It gives me the flexibility I need but takes care of a lot of the boilerplate. It's almost like a third category.

1. http://jdbi.org

You could use something like jdbi or mybatis. It's not as ugly as raw jdbc and easier to use without all of the gunk from an ORM like hibernate.

We use JDBI. Very simple and lightweight. It uses an object mapper not a full fledged ORM.

Alternatively there are... hybrid solutions like Kotlin's https://github.com/JetBrains/Exposed or https://jdbi.org/ that don't quite... do all the heavy lifting for querying but allow you to sorta stitch queries together manually.