在哪些实际场景下,人们会选择使用Spring Data JDBC / Spring Data JPA和Hibernate?我想了解何时使用这些实现最为适合。
在哪些实际场景下,人们会选择使用Spring Data JDBC / Spring Data JPA和Hibernate?我想了解何时使用这些实现最为适合。
正如@Naros所说,目前在标题中的问题并不是很适合。似乎我们应该真正考虑4个选项,并大多列出每种方法的优点,各自的缺点是其他方法的优点的缺失:
JDBC without Spring Data
您可以完全控制正在发生的事情。没有框架生成或注入任何内容。这可能听起来像一个缺点,但如果您尝试调整映射和配置以使某些JPA实现执行您可以轻松编写的Java和SQL操作,您就会明白这可能是一个很大的优点。
您无需学习JPA或Spring Data。我个人认为Spring Data很容易,但我有偏见(请参阅我的个人资料)。但是,一旦您离开简单实体和设置的领域,JPA肯定是具有挑战性的。
您可能希望使用一些库以减少样板代码。看看以下内容:
JOOQ
MyBatis
Spring JdbcTemplate(可在不使用Spring的其他功能的情况下使用)
QueryDsl
JDBC with Spring Data
您可以获得Spring Data的好处,与JDBC(参见上文)相结合:
自带CRUD方法的Repositories。
支持聚合。请参见https://spring.io/blog/2018/09/24/spring-data-jdbc-references-and-aggregates
在Spring基础设施中的良好集成,用于事务处理、依赖注入、错误翻译、分页等等。
它仍然是一个非常简单的编程模型。SQL语句会在预期的时候执行,如果需要的话,可以回退到简单的JDBC,无论是否使用其他框架的支持,都不会破坏任何抽象。
通过查询方法轻松扩展存储库(只需定义接口具有findByLastName
方法,Spring就会动态生成代码),或者使用@Query
注释或自定义方法。
支持分页
没有Spring Data的Hibernate(或其他JPA实现)
JPA可以通过JDBC做很多事情
缓存(一级、二级和查询缓存)
从查询中自动创建实例
实体之间的导航
延迟加载
跟踪对实体的更改
有了所有这些东西,理解正在发生的事情以及为什么会变得困难。当然,如果且仅如果您正确地构建应用程序结构,则可以回退到JDBC,如果JPA不提供所需功能。但我已经多次看到人们未能维护所需的结构。显然,如果您不正确地了解JPA的工作原理,这将特别困难。
使用Spring Data的Hibernate(或其他JPA实现)
我已经列出了Spring Data的好处,在心里进行复制和粘贴即可。
当然,这使得整个技术栈变得更加复杂。从许多标记有spring-data和hibernate的问题来看,似乎许多开发者都难以确定哪个工具做了什么。但是从这些问题中大多数描述的情况来看,出现问题的并不是Spring Data,而是Hibernate/JPA。
总结一下:
如果您想/需要精细地控制,请使用JDBC。
如果要使用JPA,请确保早期理解它。
如果您选择的持久化技术提供了Spring Data模块,我会使用它。这将使生活更轻松。但是请注意,我有偏见。
Spring Data JPA | Spring Data JDBC |
---|---|
独立于数据库且可移植 | 通常是特定于数据库的 |
通过对象关系映射引入复杂性 | 较简单,仍遵循Spring框架原则 |
基于实体自动生成模式 | 程序员通过DDL命令生成模式 |
自第一个版本以来就具有查询派生 | 自2.0版本以来具有查询派生 |
使用JPQL代码和本地SQL注释的查询 | 仅使用本地SQL的查询 |
可以重用带有JPA注释的类。 | 使用org.springframework.data 包中的注释 |
通过注释,如@OneToMany、@Embedded等,对实体之间的关系进行建模。 | 主要在程序员的一侧通过类的设计来建模关系。 |
缓存和延迟加载 | 无缓存、无延迟加载 |
会话和脏跟踪 | 没有会话,没有脏跟踪 |