JPA vs Spring JdbcTemplate

Question

For a new project, is the JPA always the recommended tool for processing relational data, or are there scenarios where Spring JdbcTemplate is the best choice? Some factors to consider in your answer:

• new database schema compared to existing schema and tables
• developer knowledge level
• ease of integration with data caching layer
• performance
• any other factors to consider?

Answer 1

Use Spring JdbcTemplate if you do not want to access your database schema using a domain model. Using JdbcTemplate, you use access at a lower level, with more flexibility, but probably also with more templates.

Spring JdbcTemplate can be more easily used with exotic database schemas and stored procedure focus. Using JPA, you must ensure that the database schema is correctly mapped to the domain model.

Both technologies need developers who know relational databases, SQL, and transactions. Together with JPA you get more hidden complexity.

JPA, as far as I know, is easier to connect to data caching levels, since an object-oriented focus makes identifying, updating, and canceling cache I / O easier.

You can better customize the basics based on JdbcTemplate, but in most cases more code is used.

Some other aspects to consider are that although with JPA you get a domain model for your database schema, you often have to use additional DTO classes. Using JdbcTemplate, you can work directly with DTO classes.

Answer 2

I am a little late for this post, but I tend to use JdbcTemplate for ORM. I know SQL (pretty well) and really don’t want to get distracted from my DB. I find most of the time, my applications use DB views, where I push most of the business logic. I have properly layered DAOs that have JdbcTemplate implementations. It feels "clean" and the most boilerplate code is hidden by JdbcTemplate (and its online documentation seems MUCH better than the ORM stuff). For a limited time, when I used something like Hibernate, I found that when it worked, it saved me time ... but when it didn’t work properly, it cost me days to debug WTF. I never had to spend more than 20 minutes debugging JdbcTemplate DAO impls. I think the key, as others have noted, is how comfortable you are with SQL / Schema Design.

Answer 3

I agree with @Timo. The only other understanding I would like to add / expand is that ORM has different semantics from pure access to your sql based data.

The ORM point should ignore the fact that your data is in the database as much as possible. When you use ORM correctly, all save operations are performed in a single (hopefully) thin layer. Your model objects will have almost no save code; the fact that you are using ORM should be invisible to your model.

Because of this, ORM is very good at making your life easy for certain types of operations, namely simple CRUD operations. You can load model objects, represent them, update them, and delete them easily. This makes your life easier, because when you access your data, you return model objects on which you can write business logic. If you use JDBC, you will have to “remove” your object instances from the data, which can be complex and error prone.

ORM is not always the best choice. JPA is a tool for work, if the tool is not enough for the job, you need to find the best tool. For example, I had a scenario when I had to copy the entire graph of objects and save a new copy of these objects. If I used ORM (as I tried to do this), I had to download all the objects from the database, then copy them, and then save the new objects. I have been studying for too long.

The best solution was to simply use jdbc-based operations and "paste through select" sql calls to create new rows. It was fast, the code was simpler.

Another thing to keep in mind is that you are comfortable with JDBC, and you have deadlines, you don’t have to jump on the ORM winner. The Spring JdbcTemplate classes are extremely efficient and useful. Sometimes the best tool for the job is the one you know. You should familiarize yourself with ORM, but not necessarily for a project with high expectations. There are many opportunities for learning, and its not trivial - indeed, you are trading one set of difficulties with another in choosing to use jdbc vs orm.

Answer 4

This is not mentioned in other answers, but it is good to use both. In my application I use JPA and JdbcTemplate, for operations like crud I use JPA, but for reports or where it's easier, I use jdbcTemplate.

@Repository public class FooRepository { @PersistenceContext private EntityManager entityManager; @Autowired(required = true) private JdbcTemplate jdbcTemplate; public void saveFoo(Foo foo) { this.entityManager.persist(foo); } public List<SomeReportPojo> getSomeReport() { return this.entityManager.queryForList("SELECT .. ",SomeProjectPojo.class); } } 

The great thing about Spring is that translating exceptions from JPA exceptions to Spring, the Dao exception hierarchy works with both JPA and jdbcTemplate. Therefore use JPA when it makes sense, and jdbcTemplate when it makes sense.

Answer 5

At work, we use the Hibernate JDBCTemplate because it has more flexibility. It also has better performance than JPA, because you do not load a lot of unnecessary data into your application.
With JDBCTemplate, your SQL skills have come a long way, giving you exactly what you need at the right speed.