如何區分版本庫和服務層

應該如何區分版本庫和服務？恕我直言客戶端（例如控制器）應首先使用服務層而不是存儲庫，因爲它應該與持久性實現分開。單個存儲庫應該只提供一個實體的訪問方法，而Service的方法能夠提供更復雜的操作，包括使用多個存儲庫。如何區分版本庫和服務層

但是如何處理豐富的存儲庫，它不僅提供了CRUD方法，而且還提供了更多，例如來自Spring Data的JPARepository？在這樣的實現中，有很多可能的獲取對象的方法在Service中複製它們並不酷。

那麼這個問題的解決方案是什麼？在這樣的服務層

A.重複方法

@Service 
class XService{ 

    @Autowired 
    private XRepository repository; 

    public List<X> findAll(){ 
     return repository.findAll(); 
    } 
}

B.只需用在控制器（自動裝配或訪問方法在服務）存儲庫

C.任何其他好的方法？

來源

2013-07-16 wajs

服務應實現（業務）邏輯並可能根據該邏輯修改實體。如果您的服務層只是存儲庫周圍的薄包裝器，即只根據您的描述提示獲取實體，則您的設計出現問題。

通常邏輯遍佈控制器。識別該邏輯，將其提取並封裝到服務中，並通過編排適當的服務來限制控制器管理應用程序的流程。

來源

2013-07-16 09:32:28 Pyranja

上面的服務只有一個包裝回購方法的方法，因爲它只是一個例子，我知道服務層應該負責業務邏輯，但我不知道如何處理這些簡單的方法 - 直接使用它們從Repository或將它們包裝在Service方法中。例如。讓我們考慮Controller方法，只需將List 模型化 - 我們應該使用Repository還是將該方法包裝在Service中？ – wajs

我認爲這取決於。如果你有一個健康的服務層，但只有一些簡單的「直接訪問」方法 - 就這樣吧。我會讓服務包裝它（如果出現新的要求，還可以輕鬆更改它）。另一方面，如果你的服務層被這樣簡單，愚蠢的包裝所支配，那麼就存在一個問題。一種方式是我描述的：充實服務層。或者，如果你的應用程序非常簡單並且你希望沒有實質性的變化，那就直接去掉這些「服務」並直接使用倉庫。任何非平凡的軟件都會在一定程度上違反設計原則。 – Pyranja

如何區分版本庫和服務層

回答

相關問題