為什么在彈簧控制器中使用服務層而不是輔助類？

Question

根據我的經驗，這是我如何看待使用的彈簧控制器：定義一個彈簧控制器，它將某種類型的值返回到表示層。 控制器請求映射方法調用服務層。 服務層本身由接口和實現組成。 服務接口總是只包含一個方法，因此它不是真正的多態，因為它始終保持“一個形式”。 服務實現可以訪問某種類型的數據，可能來自DAO並將其返回給控制器。 控制器可以在將其返回到表示層之前稍微修改該數據。

在這種情況下，有一個界面是什么意思？ 我從未遇到過從多個控制器調用的spring服務實現，為什么接口呢？

使用執行服務實現操作的輔助控制器類是否更有意義？

Answer 1

使用服務層是有益的，因為它允許業務邏輯與控制器任務的良好邏輯分離。 在Service類中，您可以封裝與PaymentService等特定方面相關的業務邏輯。 在PaymentService中，您可以實現各種方法，如cardPayment(), paypalPayment(), refund() 。 不同的控制器將使用單一服務。 而且，服務層也便於代碼重用。

如果您稍后決定使用某些AOP功能，在控制器和服務之間添加一些邏輯（例如日志記錄）而不更改其代碼，則使用接口很方便。

Answer 2

你是對的 - 服務接口往往是特定於用例的，但是仍然有一些很好的理由來創建一個接口：

• 這是一個很好的做法。 例如，它允許交換服務的新實現。 通過IDE提取接口確實沒有成本或負面影響。
• 允許使用DynamicProxies進行事務管理，安全性問題等。動態代理比cglib代理更快，並且它們不需要默認構造函數。 。 。 此外，在過去，具體對象的代理有時可能是片狀的，但DynamicProxies非常簡單，因此幾乎沒有出錯的空間。
• 正如Luke Taylor所說，它簡化了測試。

Answer 3

使用接口的一個很好的理由是進行測試。 如果要單獨測試控制器，那么使用接口最適合模擬或存根。

Answer 4

我認為界面是一個好主意，因為它可以讓您將業務邏輯保留在實現中，而不用擔心如何遠程公開它。 您可以將接口設置為REST或SOAP服務，EJB或您想要的任何其他內容。 獲取數據不會改變業務邏輯。 它使它與控制器完全分開。 您可以在Web層之外使用該服務。