JpaRepository使用模式？

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

} 

並沒有使用彈簧數據休息創建業務層邏輯得到CRUD REST服務（注：這只是一個例子）。

相同的東西留給控制器。