服務層是否位於控制器和模型（映射器）之間？

Question

我發現自己需要將一些功能移入服務層。在這種特殊情況下，它涉及關於zend-paginator的example。

在該示例中，服務層只是控制器和模型之間的臨時階段。看起來這是它的預期作用，並且在certain circumstances之下似乎很有道理。

它雖然給我提出了幾個問題。

首先，難道我不能輕易將示例服務代碼移動到控制器而沒有任何真正的損失，並且這不會讓我通過移除一層代碼而受益嗎？

假設移動代碼到服務層有一個實際的好處，那麼我的映射器交互的其餘部分會發生什麼？控制器是否爲一些任務訪問服務層，爲其他人訪問映射器，或者服務層是否成爲所有映射器交互的代理？

對於像從表單創建新行那樣的事情來看，服務層不會添加任何值，所以它在字面上等於服務層級的傳遞函數。

將它用於某些任務好像會使事情複雜化，而將它用作代理看起來像我們故意引入代碼複製和複雜性。

對'最佳實踐'的任何澄清都會非常有幫助。

Answer 1

將代碼移動到控制器會產生一個胖控制器。它將應用程序與UI緊密結合在一起。這使得很難在不同的背景下執行該操作。瘦型控制器通過使用一個或多個服務生成響應來處理特定上下文中的請求。

這些服務通過以鬆散耦合的方式與模型交互來定義應用程序的邊界（域邏輯），這種方式可以集成到不同的上下文中。

例如，控制器與MVC應用程序中的服務層進行交互。控制檯包裝器可以與cli上的服務層進行交互。 SOAP或JSON-RPC服務器可以使用反射將服務公開爲Web服務API。所有這些都可以在不復制代碼的情況下完成。