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

根據我的經驗，這是如何看到使用的彈簧控制器：定義一個彈簧控制器，它將某種類型的值返回到表示層。控制器請求映射方法調用服務層。服務層本身由接口和實現組成。服務接口總是隻包含一個方法，所以它不是真正的多態，因爲它始終保持「一種形式」。服務實現可能會訪問某種類型的數據，可能來自DAO並將其返回給控制器。控制器可能會稍微修改這些數據，然後再返回到表示層。爲什麼在彈簧控制器中使用服務層而不是輔助類？

在這種情況下有一個接口的這一點是什麼？我從來沒有遇到過從多個控制器調用的spring服務實現，爲什麼這個接口？

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

來源

2013-02-22 blue-sky

對服務使用接口不是強制性的。有些人使用它們來編寫服務的單元測試實現。 – mightyrick 2013-02-22 16:23:23

這是由於[Abstract Factory]（http://en.wikipedia.org/wiki/Abstract_factory_pattern）設計模式。也許在你的系統中，你只使用一個單一的服務接口實現，但你確實可以有更多的服務實現（取決於需求和應用程序設計）。 – 2013-02-22 16:24:04

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

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

來源

2013-02-22 16:24:51

使用接口的一個很好的理由是測試。如果您想單獨測試您的控制器，那麼使用界面對於模擬或存根來說是最有意義的。

來源

2013-02-22 16:24:08

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

它只是很好的做法。例如，它允許交換新的服務實現。通過IDE提取界面確實沒有成本或負面影響。
允許將DynamicProxies用於事務管理，安全問題等。動態代理比cglib代理更快，並且不需要默認構造函數。。。另外，過去，具體對象的代理有時可能是片狀的，但DynamicProxies非常簡單，沒有什麼可以出錯的地方。正如盧克泰勒提到的那樣，它簡化了測試。

來源

2013-02-23 01:26:10

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

來源

2013-02-23 01:47:10 duffymo

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

回答

相關問題