Card 07/ 07
Recap: Spring Data JDBC vs JPA
Watching versus not watching, the lazy-loading failure, aggregates, and the rule for choosing.
Spring Data JDBC and JPA come down to the five ideas below, each listed with the card that covers it.
| The idea | Where |
|---|---|
JPA's persistence context saves changed entities at commit, with no save() | JPA Persistence Context and Dirty Checking |
A lazy collection read after its transaction closes throws LazyInitializationException | LazyInitializationException: A Lazy Collection Read Outside Its Transaction |
| JDBC for flat domains and predictable SQL; JPA for deep relationships | Spring Data JDBC vs Spring Data JPA |
| Spring Data JDBC allows one repository per aggregate root | Aggregate Roots in Spring Data JDBC: One Repository per Aggregate |
A Spring Data JDBC save() writes the whole aggregate, and nothing else | Spring Data JDBC Example: Saving an Aggregate End to End |
The difference behind all five is whether the framework watches your objects. Choose the model whose answer to that question suits your domain, and the rest follows.
← → move through sections and cards