May服務註釋類在Spring框架中包含SQL/HQL嗎？

Question

我檢查了很多樣品，但是我沒有找到適當的解決方案。 有些文檔說「理想情況下，您的業務邏輯層不應該知道有一個數據庫，它不應該知道連接字符串或SQL。」

我發現了一些樣本，它們將業務邏輯定位到@Service註釋類，但他們在@Service方法中使用SQL/HQL。

應該是什麼樣的理想用法？如果我們想更改數據庫或持久性技術，我們應該只更改@Repository註釋類還是兩者？

Answer 1

我更喜歡在DAO層中放置與持久相關的所有東西（即查詢，以及處理JDBC，JPA或Hibernate的所有東西），並讓服務層依賴此DAO層持久性相關的東西。

但是主要目標不是能夠在不影響服務層的情況下更改持久性技術。例如，如果從Hibernate切換到JPA，這可能是可能的，例如，如果您從JPA切換到JDBC，則不會出現這種情況。其原因是

• JPA自動仍然存在，而無需任何更新數據庫查詢到實體所做的所有更改，而JDBC沒有，因此需要額外的更新查詢實體之間
• JPA懶加載的關聯，而JDBC不
• ...

因此改變持久化技術會影響到服務層，即使所有的持久性的東西是DAO中分離出來。

這種分離的主要優點，恕我直言，是爲每個類

• 更清晰的職責。它避免了將與持久性相關的代碼與業務邏輯代碼混合在一起。
• 可測試性：您可以通過模擬DAO層輕鬆測試您的服務層。您可以輕鬆測試DAO層，因爲它所做的只是在數據庫上執行查詢。

Answer 2

在您的服務方法中，您不應該使用任何SQL/HQL語法或任何數據庫工作。所有這些應該在DAO層，它們被註釋爲@Repository。你應該從你的服務方法中調用它們。通過這種方式，您可以在將來輕鬆更改您的分貝。否則，它會有太多的負擔

Answer 3

理想情況下，您的業務邏輯處理或組成模型域的對象。它不應該意識到持久性等問題。這就是像Hibernate一樣的O/R-Mapper。業務邏輯需要基於域屬性（如員工姓名，上個月的收入等）所需的對象。

持久層應該能夠將業務需求轉換爲SQL/HQL /服務調用或任何使用的技術所需的。因此業務邏輯層僅在業務邏輯改變時纔會改變。

這將是理想世界的目標，但實際上它不適用於非平凡的問題。你無法避免某種程度的耦合。但正如@JB Nizet所說的那樣，它可以減少耦合到合理的數量。使用TDD並遵守像SRP這樣的OO原則將幫助您達到目標。