Question

我刚刚开始使用JpaRepository，并且想知道其他人使用什么模式来处理它。我注意到我最终在我的dao层中声明了至少2个存储库。

public interface CustomerRepository extends JpaRepository<Customer, Integer> {

Customer findById(Integer id); 
Page<Customer> findByLastname(String name, Pageable pageable);

Page<Customer> findByLastnameLike(String name, Pageable pageable);

}


 public interface FilmRepository extends JpaRepository<Film, Long>

Page<Film> findByTitleLike(String name, Pageable pageable);

Page<Film> findByDescriptionLike(String name, Pageable pageable);

Film findById(Long id);

}

大多数人会推荐/尝试使用单独的控制器和服务层（每个接口1个）或尽可能多地组合使用吗？我认识到这个问题是高度针对特定应用的，但是在使用JpaRepository接口时，这方面是否有一般的最佳实践？我把它们结合在一起，坦率地说它看起来很混乱，我正在考虑重写。

Answer 1

当我编写业务层时，我更喜欢编写一个具有通用业务逻辑操作的服务。该服务可以使用多个DAO（存储库）类，并将它们组合在一起。通常，在业务服务逻辑中，不仅需要访问不同的数据库表，还需要使用其他服务（调用外部Web服务，与MQ通信，记录服务，安全服务等）。从这一切我们可以得出结论，在单业务层类中，我们必须使用多个存储库和/或其他服务类。

业务层不仅应该是访问存储库的接口，业务层在与存储库交互时应该做一些业务逻辑。

如果您的代码看起来很混乱，也许您应该尝试重构它，但我怀疑如果您隔离所有业务服务和控制器，您将获得很多好处。

但正如您所说，每种方法都是高度针对特定应用的。但是，一般来说，如果你编写CRUD应用程序，每个存储库一个业务类是很好的方法，但如果你有复杂的业务逻辑，我担心这是不可能的。

例如，您可以定义



@RestResource(path = "customer", rel="customer")
public interface CustomerRepository extends CrudRepository<Customer, Integer> {

Customer findById(Integer id);

Page<Customer> findByLastname(String name, Pageable pageable);

Page<Customer> findByLastnameLike(String name, Pageable pageable);

}

@RestResource(path = "customer", rel="customer") public interface CustomerRepository extends CrudRepository<Customer, Integer> { Customer findById(Integer id); Page<Customer> findByLastname(String name, Pageable pageable); Page<Customer> findByLastnameLike(String name, Pageable pageable); } 并通过使用spring-data-rest创建业务层逻辑来获取crud REST服务（注意：这只是一个示例）。

同样的事情留给控制器。

使用JpaRepository的模式？

1 个答案: