JPA/Hibernate只读操作最佳实践及相关技术问题咨询

Hibernate手册指出，不建议通过实体查询获取只读数据，这类查询会请求过多冗余数据。这和我们实际开发中的情况完全吻合——复杂领域模型下，这类查询运行耗时极长，处理表视图时问题尤为突出。

手册进一步强调：

对于只读事务，应采用DTO投影，这样可以仅选择特定业务场景所需的列。

但现实问题是，JPA并没有提供便捷的DTO投影实现方式，只能依赖Criteria Builder，而该工具不仅代码冗长、易出错，还经常因实现复杂度高而无法正常工作。

观察Stack Overflow上的讨论可以发现，大量开发者仍在使用实体进行只读操作。基于此，以下是三个常见疑问及对应的实践解答：

1. 实际企业应用中，避免使用只读实体查询是否普遍？ #

并不普遍。很多团队出于开发效率优先的考虑，会直接使用实体查询——毕竟实体映射完成后，调用即可获取数据，无需额外定义DTO或编写复杂的投影逻辑。尤其是在业务初期、数据规模较小时，实体查询的性能问题并不显著，团队不会特意切换到DTO投影。只有当系统数据量增长、性能瓶颈显现时，才会逐步优化，改用投影查询。

2. 如果要规避只读实体查询，有哪些工具可以简化操作？ #

有不少成熟工具能解决这个痛点，主流的包括：

• jOOQ：这是一款广泛使用的类型安全查询DSL工具，可直接编写接近原生SQL的代码，并轻松映射到DTO，彻底摆脱Criteria Builder的繁琐。它支持绝大多数主流数据库，且能与Spring无缝集成。
• Spring Data Projections：Spring Data原生支持接口投影和类投影，无需编写复杂查询逻辑，只需定义好投影接口或类，Spring Data会自动生成对应的SQL并返回所需数据。
• Blaze-Persistence：这是基于JPA的扩展框架，提供了更强大的查询DSL，支持DTO投影、分页、复杂关联查询等功能，比Criteria Builder易用得多。

3. 有没有讲解Spring应用与持久层连接的架构最佳实践的资源？ #

当然有，这类资源主要集中在官方文档和权威技术资料中：

• Spring官方文档：Spring Framework和Spring Data的官方文档包含了事务管理、持久层集成的详细最佳实践，比如声明式事务的正确使用、不同持久化技术的集成方案等。
• Spring官方博客：经常发布关于持久层架构、事务优化的实战文章，均为一线工程师的经验总结。
• 权威技术书籍：例如《Spring实战》《Spring Data实战》这类书籍，会系统讲解Spring与持久层的架构设计，涵盖事务管理、性能优化、架构分层等内容，能帮助搭建更规范的持久层架构，避免临时方案带来的问题。

内容的提问来源于stack exchange，提问作者Kyle Condon