Hibernate和Spring Data JPA有什么区别

Question

Hibernate和Spring Data JPA之间的主要区别是什么？什么时候不应该使用Hibernate或Spring Data JPA？另外,什么时候Spring JDBC模板的性能比Hibernate/Spring Data JPA好？

Answer 1

Hibernate是一个JPA实现,而Spring Data JPA是一个JPA数据访问抽象.Spring Data提供GenericDao自定义实现的解决方案.它还可以通过方法名称约定代表您生成JPA查询.

使用Spring Data,您可以使用Hibernate,Eclipse Link或任何其他JPA提供程序.一个非常有趣的好处是您可以使用@Transactional注释以声明方式控制事务边界.

Spring JDBC更轻量级,它用于本机查询,如果您只打算单独使用JDBC,那么最好使用Spring JDBC来处理JDBC详细程度.

因此,Hibernate和Spring Data是互补而不是竞争对手.

Answer 2

我们在这里使用了3种不同的东西:

1. JPA:Java持久性api,它提供了从java对象到数据库中的关系的持久化,读取,管理数据的规范.
2. Hibernate:有各种提供程序实现jpa.Hibernate就是其中之一.所以我们也有其他提供商.但是如果使用带弹簧的jpa,它允许你将来切换到不同的提供商.
3. Spring Data JPA:这是jpa之上的另一层,春天提供让你的生活更轻松.

因此,让我们了解spring数据jpa和spring + hibernate的工作原理 -

Spring Data JPA:

假设您正在为您的应用程序使用spring + hibernate.现在你需要有dao接口和实现,你将使用hibernate的SessionFactory编写crud操作.假设您正在为Employee类编写dao类,明天在您的应用程序中,您可能需要为任何其他实体编写类似的crud操作.所以我们可以在这里看到很多样板代码.

现在,Spring数据jpa允许我们通过扩展其存储库(crudrepository,jparepository)来定义dao接口,以便它在运行时为您提供dao实现.你不需要再写dao实现了.看看spring data jpa如何让你的生活更轻松.

Answer 3

我不同意SpringJPA使现场变得容易.是的,它提供了一些类,你可以快速制作一些简单的DAO,但实际上,你可以做到.如果你想做更多的事情而不是findById()或保存,你必须经历地狱:

• org.springframework.data.repository类中没有EntityManager访问权限(这是基本的JPA类!)
• 自己的事务管理(不允许hibernate事务)
• 多个数据源配置存在巨大问题
• 没有数据源池(HikariCP必须作为第三方库使用)

为什么自己的交易管理是一个劣势？由于Java 1.8允许将默认方法转换为接口,因此基于Spring注释的事务简单不起作用.

不幸的是,SpringJPA基于反射,有时您需要将方法名称或实体包指向注释(!).这就是为什么任何重构都会导致严重崩溃的原因.可悲的是,@ Transactal仅适用于主DS :(因此,如果您有多个DataSource,请记住 - 事务只适用于主要的:)

Hibernate和Spring Data JPA之间的主要区别是什么？

Hibernate是JPA兼容,SpringJPA Spring兼容.您的HibernateJPA DAO可以与JavaEE或Hibernate Standalone一起使用,当SpringJPA可以在Spring中使用时 - 例如SpringBoot

什么时候不应该使用Hibernate或Spring Data JPA？另外,什么时候Spring JDBC模板的性能比Hibernate/Spring Data JPA好？

仅在需要使用多个联接或需要使用具有多个数据源连接的Spring时才使用Spring JDBC.通常,避免JPA加入.

但我的一般建议,使用新鲜的解决方案 - Daobab(http://www.daobab.io).Daobab是Java和任何JPA引擎集成商,将在您的任务中提供很多帮助:)

Answer 4

Spring Data是一个方便的库，JPA它抽象了许多东西，并将 Spring 的魔力（不管喜欢与否）带到了持久性存储访问中。它主要用于处理关系数据库。简而言之，它允许您声明具有类似方法的接口findByNameOrderByAge(String name);将在运行时解析并转换为适当的JPA查询的。

它位于 的顶部JPA使其具有诱人的用途：

1. 不了解SQL或不了解的菜鸟开发者。这是灾难的秘诀，但如果项目微不足道，他们可以逃脱。

2. 经验丰富的工程师，他们知道自己在做什么，并希望快速解决问题。这可能是一个可行的策略（但请进一步阅读）。

根据我的经验Spring Data，它的魔力太大了（这适用Spring于一般情况）。我开始在一个项目中大量使用它，最终遇到了几个极端情况，在这些情况下我无法摆脱库，最终得到了丑陋的解决方法。后来我阅读了其他用户的投诉，并意识到这些问题对于Spring Data. 例如，检查这个导致数小时调查/咒骂的问题：

 public TourAccommodationRate createTourAccommodationRate(
        @RequestBody TourAccommodationRate tourAccommodationRate
    ) {
        if (tourAccommodationRate.getId() != null) {
            throw new BadRequestException("id MUST NOT be specified in a body during entry creation");
        }

        // This is an ugly hack required for the Room slim model to work. The problem stems from the fact that
        // when we send a child entity having the many-to-many (M:N) relation to the containing entity, its
        // information is not fetched. As a result, we get NPEs when trying to access all but its Id in the
        // code creating the corresponding slim model. By detaching the entity from the persistence context we
        // force the ORM to re-fetch it from the database instead of taking it from the cache

        tourAccommodationRateRepository.save(tourAccommodationRate);
        entityManager.detach(tourAccommodationRate);
        return tourAccommodationRateRepository.findOne(tourAccommodationRate.getId());
    }

我最终降低了级别并开始使用JDBI- 一个不错的库，具有足够的“魔法”，可以将您从样板中拯救出来。有了它，您就可以完全控制 SQL 查询，而且几乎不必与库作斗争。