0

我刚刚开始使用 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 接口时是否有这方面的一般最佳实践？我最终将它们结合起来，坦率地说，它看起来一团糟，我正在考虑重写。

4

1 回答 1

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);

}

并通过使用 spring-data-rest 获得 crud REST 服务，而无需创建业务层逻辑（注意：这只是一个示例）。

同样的事情也适用于控制器。

于 2013-03-19T09:42:00.297 回答