Question

我已经读过，如果可能，您应该使用CrudRepository或PagingAndSortingRepository而不是JpaRepository，这样您就不会将代码与特定于商店的实施相结合，但有没有JpaRepository是更好的选择？

对于我的应用程序，我们需要使用saveAndFlush()方法和flush()方法立即刷新数据库更改，因为我们正在尝试将两个实体合并在一起并且不想运行错误的独特关键条件。

例如：

public class User {
    @Id
    String userId;

    @OneToMany(mappedBy = "user")
    private Collection<Address> addresses;

    // getter and setter methods
}

public class Address {

    @ManyToOne(optional = false)
    private  User user;

    // Other fields
    // getter and setter methods
}

public void mergeDuplicateUserAddresses(User user, User duplicateUser) {
    String userId = user.getUserId();
    List<Address> addresses = duplicateUser.getAddresses()

    for (Address address : addresses) {
        address.setUser(userId);
        addressesRepository.saveAndFlush(address);
    }
}

对于这个例子，我看到使用JpaRepository而不是CrudRepository，但是有没有其他方法可以减少特定于商店的使用？

Answer 1

只需使用JpaRepository并对它感到满意。基础数据源类型的变化实际上是一种罕见的情况，当它发生时，无论如何都需要进行更大的更改。不同的数据源类型实际上需要不同的处理。我知道经常会发生一些人说你应该从数据源类型中抽象出来，以便你可以轻松地改变它。但不确定他们是否尝试过。

为什么它不起作用的一些论据（如果你需要与某人争论）

更改底层关系数据库通常不起作用。是的JPA应该是它的抽象层，但它并不适用于所有情况。当您更改jpa提供程序时，您也会遇到麻烦。他们都有自己的特点。
当您更换日期来源f.e.从关系到noe4j。你怎么处理你的@Query东西。对不起，我必须说，但neo4j不懂sql。
您必须始终牢记交易处理。您的数据源是否完全支持事务以及它们的行为方式。例如关系和neo4j。两者都有一个事务系统，但它们完全不同，在将代码直接迁移到neo4j时会遇到麻烦。原因是neo4j具有更严格的锁定行为。
您的业务层可能取决于特定提取行为的性能原因，但如果您交换数据源类型会发生什么。这些不同的数据源类型是否支持替代提取行为。或者是否有必要修改业务层的工作原理？

故事。更改数据源类型通常比实现不同的接口更麻烦。

使用JpaRepository而不是CrudRepository

1 个答案: