Spring in Action - JPA and Hibernate

[Mike Gosling]

At University, I had email client type of project assignment and I was the best in my class, as professor pointed out. However, I was using bunch of tutorials and blogs on how to use and persist data using Hibernate.

Since we all know that Hibernate is an implementation of JPA, my question for you is, can a beginner using your book, understand JPA well enough so he/she can further deep dive into Hibernate.

In what style do you teach and display usage of JPA (or Hibernate)?

And maybe a bit broader question, what would be your tip or strategy on how to tackle "the beast" (not counting buying your book haha just kidding)

Cheers!

[Tim Holloway]

I have a 2003(!) edition of Spring in Action, and even back then there was a topic on Hibernate with Spring (Spring Data). It was only a chapter, and JPA has entire books devoted solet to JPA itself, but it's a start.

One thing I should note, though is that Hibernate "isn't" JPA. Hibernate is older than JPA and was a contributor to the JPA standard. So now there are two types of Hibernate: Legacy Hibernate and Hibernate JPA. They are much alike, but they are not the same.  Spring supports both versions of Hibernate. As well as other JPA products such as Apache OpenJPA. And by extension, EJB, since JPA is a subset of the EJB 3 standard, although Spring Data aspires to do "EJB" better than EJB does.

I mention the difference because an awful lot of people ask questions here on the Ranch and they're using Legacy Hiibernate. Likewise, if you go searching the web for "Spring Hibernate", you'll probably find both versions. I don't recommend legacy Hibernate, since to the best of my knowledge JPA does everything the original Hibernate did and it's likely that Legacy Hibernate will eventually become unsupported. But in the mean time, make sure you know which flavor of Hibernate you got your code samples from. And nothing lingers on the Internet like obsolete information, except maybe for outright lies. But that's a different story. I spent years admonishing people not to use obsolete JSF constructs.

[Craig Walls]

I'll be brutally honest...I'm not a huge fan of JPA (or ORM in general). When I first learned ORM (anybody remember Castor?), I thought it was amazing. I could map objects to table and properties to columns and it was like magic! Except that it wasn't magic...I still had to define the mapping. And what I learned from all of that is that I'm pretty good at writing SQL, but I'm HORRIBLE at defining mappings...especially if the database schema deviates (as it often does) from the domain model. Therefore, although I still do some JPA from time to time, I would prefer JDBC (well, Spring's abstraction of JDBC) over JPA any day.

That said, if you must do JPA, then there's no way to avoid the mapping. It's just so essential to JPA. Therefore, since I can't eliminate mapping pain, I seek ways to reduce pain in writing repositories. Before Spring Data JPA, I observed that all of my repositories, regardless of the domain, looked pretty much the same. My repositories were just thing wrappers around EntityManager and had (more or less) the exact same methods. I hated it. But if I'm going to do JPA today, then Spring Data JPA is the way to go. Let Spring handle all of the EntityManager stuff and just write a repository interface. Easy-peasy (except for the mapping stuff).

So yeah...my book covers JPA using Spring Data JPA. What's nice about that is that the programming model for Spring Data JPA is nearly identical to working with Spring Data Cassandra, Spring Data JDBC, Spring Data MongoDB, ... etc. There are subtle differences, but for the most part, once you know how to work with one kind of database with Spring Data, it's easy to apply that know-how to another kind of database. And, in fact, the book will cover Spring Data JPA, SD-JDBC, SD-MongoDB, and SD-Cassandra.

[Tim Holloway]

Craig just doesn't know how to have fun. ORM/JPA is not only fun, but productive. Benchmarks have shown that using an ORM can sometimes be twice as efficient as raw JDBC, even as (counter-intuitively) modern compilers can be much more efficient than assembly language when you scale up.

Besides, ORMs virtually eliminate the dreaded SQL JOIN. Which is worth something all by itself. A whole lot of something.

If Castor was part of Lutris, then yes, I remember it, although that was so long ago I don't remember details. My first industrial-grade introduction fo ORM was via Kodo JDO (before Oracle bought them). When the JPA standard came out, Oracle re-worked it into Apache OpenJPA, keeping many of the original team members to support it.

Which, by roundabout way of saying that if you detest doing ORM Entity field-mapping in bulk, OpenJPA has tools to map from existing databases automatically.

Just about all forms of database access are tricky. You not only have to maintain transaction contexts, you have to ensure you don't release resource leak resources - a common fault in manual JDBC code is skipping the close() of JDBC objects if they get thrown. Spring deals with that automatically and it abstracts and encapsulates transaction management as well, which has allowed me to create a very productive and reliable 2-level persistent data architecture that I use routinely.

And, incidentally, in addition to JPA, Spring Data works quite well with the Neo4J graph database. It also supports things like MongoDB for your NoSQL needs..

[Craig Walls]

Tim: In no way am I judged anyone who likes ORM or suggesting that you shouldn't use it. There are obvious benefits and, as I even stated, I am known to use it from time to time. I just don't enjoy it much when I do.

But yeah, Spring Data is amazing for ANY kind of persistence, whether it be JPA or JDBC for relational databases, MongoDB, Neo4j, Cassandra, Redis, etc, etc, etc, etc, etc. And there's so much more you can do with it beyond just creating repositories. I'm especially a big fan of Spring Data projections which take query's response and "project" it onto an otherwise completely unrelated type that just happens to share some of the same properties. What's more, if you look closely at the queries that are executed for projections (at least when query logging is turned on for JPA), you'll notice that the queries are optimized for what's needed in the projection. E.g., if the entity has 10 properties, but it's being projected onto an object with 2 properties, the query will only fetch those 2 properties and disregard any unnecessary joins. It's really quite awesome.