Use Spring JdbcTemplate if you don't want to access your database schema via a domain model. Using JdbcTemplate you are using a lower level access, with more flexibility, but probably also more boilerplate.
Spring JdbcTemplate can be more easily used with exotic database schemas and a stored procedure focus. Using JPA you need to make sure that database schema maps correctly to the domain model.
Both technologies need developers knowing relational databases, SQL and transactions. With JPA you get more hidden complexity though.
JPA is to my knowledge more easily pluggable to data caching layers, since the object oriented focus makes cache entry identification, update and invalidation easier.
You can fine tune JdbcTemplate based backends better, but there is for most cases more code involved.
Some other aspect to consider is that although with JPA you get a domain model for your database schema you will often need to use additional DTO classes. Using JdbcTemplate you can directly operate with DTO classes.
2023 年 SQL/架构设计编辑的适应程度如何 - 自从我发布这个原始答案以来已经很长时间了。围绕 ORM 的工具已经取得了长足的进步。 Spring Data 和 JPA 现在已成为标准，并且具有合理的默认值。我开始欣赏编写 SQL 时的编译安全性。我不认为这是对错的问题......它们都是你应该在你的工具带上拥有的工具
I'm a bit late to this post, but I tend to use JdbcTemplate over ORM. I know SQL (pretty well) and really don't want to be "abstracted" away from my DB. I find most of the time, my apps are using DB views where I push most business logic up to. I have properly layered DAOs that have JdbcTemplate implementations. It feels "clean" and most boilerplate code is hidden by JdbcTemplate (and it's online documentation seems MUCH better then ORM stuff). The limited time I've used something like Hibernate, I found when it worked, it save me some time...but when it wasn't working properly, it cost me days of "WTF" debugging. I've never had to spend more then 20 minutes debugging JdbcTemplate DAO impls. I think the key, as others noted, is how comfortable you are with SQL / Schema Design
EDIT in 2023 - it's been a LONG time since I posted this original answer. Tools around ORM have come a LONG way. Spring Data and JPA are now standard and have sensible defaults. I have come to appreciate having compilation safety when writing SQL. I don't think it's a matter of wrong or right....they are both tools you should have in your tool belt
I agree with @Timo. The only other insight I would add/expand upon is that ORM has different semantics from pure sql access to your data.
The point of ORM is to abstract away the fact that your data is in a DB at all, as much as possible. When you use ORM properly, all persistence operations are dealt with in one (hopefully) thin layer. Your model objects will have little to no persistence 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 your model objects, present them, update them, delete them quite easily. It makes your life easier because when you access your data, you get model objects back, on which you can write business logic. If you use JDBC, you will have to 'hydrate' your object instances from the data, which can be complicated and error-prone.
ORM is not always the best choice. JPA is a tool for a job, if the tool is not sufficient for the job you will want to find a better tool. For example, I had a scenario where I had to copy an entire object graph and save a new copy of those objects. If I had used ORM (like I tried to do), I had to load all the objects out of the DB, then copy them, then save the new objects. I took way too long.
The better solution was simply to use jdbc based operations and 'insert via select' sql calls to create the new rows. It was fast, the code was simpler.
The other thing to consider is that you are comfortable with JDBC, and have deadlines, you don't have to jump on the ORM bandwagon. The Spring JdbcTemplate classes are extremely powerful and helpful. 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 is a lot to learn and its not trivial -- really you are trading one set of complexities with another in the choice to use jdbc vs orm.
@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.jdbcTemplate.queryForList("SELECT .. ",SomeProjectPojo.class);
}
}
Spring 的伟大之处在于，从 JPA 异常到 Spring Dao 异常层次结构的异常转换适用于 JPA 和 jdbcTemplate。因此，在有意义时使用 JPA，在有意义时使用 jdbcTemplate。
It is not mentioned in the other answers but it is fine to use both. In my App I use JPA and JdbcTemplate, for crud type operations I use JPA but for reporting or where it is 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.jdbcTemplate.queryForList("SELECT .. ",SomeProjectPojo.class);
}
}
The great thing about Spring is that the exception translation from JPA exceptions to spring Dao exception hierarchy works with both JPA and jdbcTemplate. So use JPA when it makes sense and jdbcTemplate when it makes sense.
At work we use Hibernate JDBCTemplate because it has more flexibility. It also has better performance than JPA because you are not "loading" a lot of unnecessary data into your app. In the JDBCTemplate case, your SQL skills go a long way in giving you exactly what you need at the right speed.
发布评论
评论（5）
如果您不想通过域模型访问数据库模式，请使用 Spring JdbcTemplate。使用 JdbcTemplate，您使用的是较低级别的访问，具有更大的灵活性，但可能也有更多的样板。
Spring JdbcTemplate 可以更轻松地与奇异的数据库模式和存储过程焦点一起使用。使用 JPA，您需要确保数据库模式正确映射到域模型。
这两种技术都需要开发人员了解关系数据库、SQL 和事务。不过，使用 JPA，您会获得更多隐藏的复杂性。
据我所知，JPA 更容易插入数据缓存层，因为面向对象的焦点使得缓存条目识别、更新和失效变得更容易。
您可以更好地调整基于 JdbcTemplate 的后端，但大多数情况下会涉及更多代码。
需要考虑的其他一些方面是，尽管使用 JPA，您可以获得数据库架构的域模型，但您通常需要使用其他 DTO 类。使用JdbcTemplate您可以直接操作DTO类。
Use Spring JdbcTemplate if you don't want to access your database schema via a domain model. Using JdbcTemplate you are using a lower level access, with more flexibility, but probably also more boilerplate.
Spring JdbcTemplate can be more easily used with exotic database schemas and a stored procedure focus. Using JPA you need to make sure that database schema maps correctly to the domain model.
Both technologies need developers knowing relational databases, SQL and transactions. With JPA you get more hidden complexity though.
JPA is to my knowledge more easily pluggable to data caching layers, since the object oriented focus makes cache entry identification, update and invalidation easier.
You can fine tune JdbcTemplate based backends better, but there is for most cases more code involved.
Some other aspect to consider is that although with JPA you get a domain model for your database schema you will often need to use additional DTO classes. Using JdbcTemplate you can directly operate with DTO classes.
我写这篇文章有点晚了，但我更倾向于使用 JdbcTemplate 而不是 ORM。我非常了解 SQL，并且真的不想从我的数据库中“抽象”出来。我发现大多数时候，我的应用程序都使用数据库视图，我将大部分业务逻辑推到其中。我已经正确分层了具有 JdbcTemplate 实现的 DAO。它感觉“干净”，并且大多数样板代码都被 JdbcTemplate 隐藏（而且它的在线文档似乎比 ORM 的东西好得多）。我使用 Hibernate 这样的东西的时间有限，我发现当它工作时，它节省了我一些时间……但是当它不能正常工作时，它花费了我几天的“WTF”调试时间。我从来不需要花费超过 20 分钟来调试 JdbcTemplate DAO 实现。正如其他人指出的那样，我认为关键是您对
2023 年 SQL/架构设计编辑的适应程度如何 - 自从我发布这个原始答案以来已经很长时间了。围绕 ORM 的工具已经取得了长足的进步。 Spring Data 和 JPA 现在已成为标准，并且具有合理的默认值。我开始欣赏编写 SQL 时的编译安全性。我不认为这是对错的问题......它们都是你应该在你的工具带上拥有的工具
I'm a bit late to this post, but I tend to use JdbcTemplate over ORM. I know SQL (pretty well) and really don't want to be "abstracted" away from my DB. I find most of the time, my apps are using DB views where I push most business logic up to. I have properly layered DAOs that have JdbcTemplate implementations. It feels "clean" and most boilerplate code is hidden by JdbcTemplate (and it's online documentation seems MUCH better then ORM stuff). The limited time I've used something like Hibernate, I found when it worked, it save me some time...but when it wasn't working properly, it cost me days of "WTF" debugging. I've never had to spend more then 20 minutes debugging JdbcTemplate DAO impls. I think the key, as others noted, is how comfortable you are with SQL / Schema Design
EDIT in 2023 - it's been a LONG time since I posted this original answer. Tools around ORM have come a LONG way. Spring Data and JPA are now standard and have sensible defaults. I have come to appreciate having compilation safety when writing SQL. I don't think it's a matter of wrong or right....they are both tools you should have in your tool belt
我同意@Timo 的观点。我要添加/扩展的唯一其他见解是 ORM 与对数据的纯 sql 访问具有不同的语义。
ORM 的要点是尽可能地抽象出数据位于数据库中的事实。当您正确使用 ORM 时，所有持久性操作都在一个（希望如此）薄层中处理。您的模型对象将几乎没有持久性代码；您使用 ORM 的事实对于您的模型来说应该是不可见的。
因此，ORM 非常擅长使某些类型的操作（即简单的 CRUD 操作）变得轻松。您可以轻松加载模型对象、呈现它们、更新它们、删除它们。它使您的生活变得更轻松，因为当您访问数据时，您会返回模型对象，您可以在其上编写业务逻辑。如果您使用 JDBC，则必须从数据中“水化”对象实例，这可能很复杂且容易出错。
ORM 并不总是最好的选择。 JPA 是一个工作工具，如果该工具不足以完成工作，您将需要找到一个更好的工具。例如，我有一个场景，我必须复制整个对象图并保存这些对象的新副本。如果我使用了 ORM（就像我尝试做的那样），我必须从数据库中加载所有对象，然后复制它们，然后保存新对象。我花了太长时间。
更好的解决方案是简单地使用基于 jdbc 的操作和“通过 select 插入”sql 调用来创建新行。速度很快，代码也更简单。
另一件需要考虑的事情是，您对 JDBC 感到满意，并且有最后期限，您不必赶上 ORM 潮流。 Spring JdbcTemplate 类非常强大且有用。有时，最适合这项工作的工具就是您所知道的工具。您应该熟悉 ORM，但不一定适合期望很高的项目。有很多东西需要学习，而且并不是微不足道的——实际上，在选择使用 jdbc 与 orm 时，您是在用一组复杂性与另一组复杂性进行交换。
I agree with @Timo. The only other insight I would add/expand upon is that ORM has different semantics from pure sql access to your data.
The point of ORM is to abstract away the fact that your data is in a DB at all, as much as possible. When you use ORM properly, all persistence operations are dealt with in one (hopefully) thin layer. Your model objects will have little to no persistence 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 your model objects, present them, update them, delete them quite easily. It makes your life easier because when you access your data, you get model objects back, on which you can write business logic. If you use JDBC, you will have to 'hydrate' your object instances from the data, which can be complicated and error-prone.
ORM is not always the best choice. JPA is a tool for a job, if the tool is not sufficient for the job you will want to find a better tool. For example, I had a scenario where I had to copy an entire object graph and save a new copy of those objects. If I had used ORM (like I tried to do), I had to load all the objects out of the DB, then copy them, then save the new objects. I took way too long.
The better solution was simply to use jdbc based operations and 'insert via select' sql calls to create the new rows. It was fast, the code was simpler.
The other thing to consider is that you are comfortable with JDBC, and have deadlines, you don't have to jump on the ORM bandwagon. The Spring JdbcTemplate classes are extremely powerful and helpful. 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 is a lot to learn and its not trivial -- really you are trading one set of complexities with another in the choice to use jdbc vs orm.
其他答案中没有提到，但两者都可以使用。在我的应用程序中，我使用 JPA 和 JdbcTemplate，对于 CRUD 类型操作，我使用 JPA，但对于报告或更容易的地方，我使用 jdbcTemplate。
Spring 的伟大之处在于，从 JPA 异常到 Spring Dao 异常层次结构的异常转换适用于 JPA 和 jdbcTemplate。因此，在有意义时使用 JPA，在有意义时使用 jdbcTemplate。
It is not mentioned in the other answers but it is fine to use both. In my App I use JPA and JdbcTemplate, for crud type operations I use JPA but for reporting or where it is easier I use jdbcTemplate.
The great thing about Spring is that the exception translation from JPA exceptions to spring Dao exception hierarchy works with both JPA and jdbcTemplate. So use JPA when it makes sense and jdbcTemplate when it makes sense.
在工作中我们使用Hibernate JDBCTemplate，因为它具有更大的灵活性。它还具有比 JPA 更好的性能，因为您不会将大量不必要的数据“加载”到您的应用程序中。
在 JDBCTemplate 案例中，您的 SQL 技能对于以正确的速度提供您所需要的内容大有帮助。
At work we use Hibernate JDBCTemplate because it has more flexibility. It also has better performance than JPA because you are not "loading" a lot of unnecessary data into your app.
In the JDBCTemplate case, your SQL skills go a long way in giving you exactly what you need at the right speed.