data access
JdbcTemplate vs JPA
Choose JPA for object-graph mapping; choose JdbcTemplate (or jOOQ) for SQL control, bulk operations, and reporting.
JPA and JdbcTemplate are two levels of abstraction over the same database, and choosing between them is about how much control over the SQL you need versus how much mapping you want done for you. They are not rivals so much as tools for different jobs, and mature applications often use both.
JPA is a tour bus — comfortable, fixed routes. JdbcTemplate is a rental car — you drive, you choose every turn.
Key Concepts
1
JPA/Hibernate is an object-relational mapper: you work with entity objects and their relationships, and the framework generates SQL, manages a persistence context with caching and dirty checking, and handles change tracking. It shines for transactional, object-graph-centric work — loading an order with its line items, mutating them, and letting Hibernate figure out the inserts and updates. The cost is a layer of indirection that can generate surprising or inefficient SQL and a learning curve around fetching, flushing, and the persistence context. JdbcTemplate sits much closer to the metal: you write the SQL yourself and provide a RowMapper to turn result rows into objects, while Spring handles connection management, statement preparation, and exception translation. You get exact control over the query, predictable performance, and a natural fit for bulk operations, complex reporting joins, and stored procedures — at the price of writing and maintaining the SQL and mapping by hand.
JdbcTemplateRowMapper
2
The interview-ready summary is to reach for JPA when the domain is an object graph you mutate transactionally and you value mapping convenience, and for JdbcTemplate (or jOOQ, which adds type-safe SQL) when you need precise SQL, bulk efficiency, or reporting queries that JPA would model awkwardly. The pragmatic answer is that they coexist: JPA for the bread-and-butter CRUD and aggregate persistence, JdbcTemplate for the handful of performance-critical or report-shaped queries where you want the SQL to be exactly what you wrote.
3
What the interviewer is probing.
What the interviewer is probing.
4
1. "When would you choose JdbcTemplate?" *Probing:* the judgement. *Stalls:* "Never." *Moves
up:* complex reporting queries, bulk operations, and anywhere the object graph is irrelevant — it is
simpler and the SQL is visible.
1. "When would you choose JdbcTemplate?"
5
2. "What does JPA give you that justifies its complexity?" *Probing:* the other side. *Stalls:*
"Nothing." *Moves up:* identity management, dirty checking, cascading and the persistence context —
real value for transactional object graphs.
2. "What does JPA give you that justifies its complexity?"
6
3. "Can you use both?" *Probing:* the pragmatism. *Stalls:* "No." *Moves up:* yes, in one
application and even one transaction — but mixing within a unit of work needs care over the flush
order.
3. "Can you use both?"
7
4. "What is JdbcClient?" *Probing:* currency. *Stalls:* "Nothing." *Moves up:* the newer fluent
API over JdbcTemplate in recent Spring, which is the one to reach for in new code.
4. "What is JdbcClient?"