摘要：一個動作類，應該有一個能夠說明其功能的名字，比如等。如果需要對我們的動作類實現(xiàn)某種適配器模式，這是非常方便的。使用單動作類的好處小巧而單一的邏輯域能夠防止代碼重復并提高代碼的可重用性，保持穩(wěn)定。易于針對各種場景進行獨立測試。

當我們談論到應用程序的架構(gòu)的時候，經(jīng)常會問到一個經(jīng)典的問題，那就是“這段代碼應該放在哪里比較好”。 因為 Laravel 是一個相當靈活的框架，所以要回答這個問題其實沒那么容易。我應該把我的業(yè)務邏輯寫在 Model 層，還是 Controller 層，或者是其他地方？

當你的應用程序僅有一個接入點，把業(yè)務邏輯寫在 Controller 層是可以的。但是現(xiàn)在更普遍的的情形是，有很多接入點去調(diào)用相同的功能模塊。

比如說，太多數(shù)的應用程序都有用戶注冊的功能，它的流程是調(diào)用一個控制器然后返回一個注冊成功或者失敗的視圖。假如這個應用程序還有移動端，那就很可能要提供一套針對移動端用戶注冊的 API ，因為它需要返回的數(shù)據(jù)格式是 JSON 。而且利用 Laravel 的 artisan 命令來創(chuàng)建用戶也很常見，尤其是在項目前期的開發(fā)階段。

上面這兩段代碼可能看起來沒有什么問題的，但是，隨著業(yè)務邏輯的增加，就會顯得代碼很冗余。舉個例子，如果你需要新用戶注冊完之后，增加給用戶發(fā)送郵件通知的功能，你必須要再上面兩個控制器中都添加發(fā)送郵件的代碼。但是如果要保持代碼的簡潔優(yōu)雅，我們可以把這些業(yè)務邏輯寫到其他地方。

對于“把業(yè)務邏輯代碼寫到哪里”的這個問題，你去任何論壇都可以得到一個普遍的答案，那就是 “使用一個 service 層，然后在 controller 層調(diào)用這個服務類”。是的，沒錯，問題是我們應該怎么設(shè)計 service 類？是創(chuàng)建一個 UserService 類來實現(xiàn)所有跟用戶用戶有關(guān)的業(yè)務邏輯，然后把這個類注入到需要用到的 Controller 層？或者是還有其他方案？

首先，可以嘗試為一個特定的模型創(chuàng)建一個單一類，其中包含所有的代碼。例如：

看起來很完美：我們可以任何控制器中申明或者使用 create/delete 方法，并且得到我們想要的結(jié)果。但是，這種實現(xiàn)有什么問題呢？ 那就是我們在解決問題的過程通常很少使用單一的模型? 。

比如說，當我們給一個用戶創(chuàng)建了賬號的時候，也要同時給用戶多帶帶創(chuàng)建一個 blog 。如果按照當前的方式去實現(xiàn)這個流程，我們就必須創(chuàng)建一個 BlogService 類，然后將其依賴注入到 UserService 類。

顯而易見，隨著應用程序的業(yè)務的增長，將會有幾十到上百個 service 類，其中的一些 service 類需要依賴 5 到 6 個其他 service 類，最終的結(jié)果就是，出現(xiàn)代碼的冗余跟混亂的局面，而這個局面是我們想不惜一切代價去避免的。

那么，如果不是用一個單一的服務類加上幾個方法，我們決定把它分成幾個類？下面是我最近每一個項目都采用的方法，結(jié)果很不錯，推薦給大家。

首先，讓我們拋棄過于籠統(tǒng)和模糊的服務術(shù)語，來了解一下我們的新動作類，并定義它們是什么以及它們可以做什么。

一個動作類，應該有一個能夠說明其功能的名字，比如：CreateOrder, ConfirmCheckout, DeleteProduct, AddProductToCart等。

它應該有且只有一個公共方法，作為 API 。理想的情況下，應該是相同的方法名，像 handle() 或者 execute() 。如果需要對我們的動作類實現(xiàn)某種適配器模式，這是非常方便的。

它必須對請求和響應不可知。它不處理請求，也不發(fā)送響應。這樣的職責應該由控制器來承擔。

它可以依賴其它的動作類。

如果有任何事情阻止它執(zhí)行和/或返回期望的值，那么它必須通過拋出一個 Exception 來強制執(zhí)行相關(guān)的業(yè)務邏輯，并且讓調(diào)用者（或者 Laravel 的 ExceptionHandler ）來承擔如何呈現(xiàn)/響應異常的責任。

現(xiàn)在，讓我們看看前面的例子，并用一個單動作類來重構(gòu)它，我們將命名為 CreateUser 。

你或許想知道當郵箱地址已經(jīng)被占用時，該方法為什么會拋出了異常。 這難道不是請求驗證來保證的嗎？當然可以。然而，在動作類內(nèi)部來執(zhí)行業(yè)務邏輯不是更好嗎？這樣使得邏輯變得易于理解和調(diào)試。

讓我們看看使用我們動作類之后的控制器代碼，如下：

現(xiàn)在，無論我們做什么修改，用戶注冊過程都會由 API 和 Web 版本處理，優(yōu)雅整潔。

假如，我們需要一個動作類將 1000 個用戶導入我們的應用中。我們可以寫一個動作類，并且繼續(xù)使用上文的 CreateUser 類：

非常整潔，不是嗎？我們可以通過將其嵌入在?Collection::map() 方法中來重用 CreateUser 代碼，然后返回所有新建用戶的集合。當郵件被占用的時候，我們可以通過返回 Null Object 或者在 Log 文件中記錄一下，你應該已經(jīng)想到了。

現(xiàn)在，假設(shè)我們想在日志中記錄每一個新注冊的用戶。我們可以將代碼寫在動作類內(nèi)部，也可以使用裝飾者模式。

然后，我們可以使用 Laravel 的 IoC 容器將?LogCreateUser?類綁定到 CreateUser?類，所有每當我們需要一個后者的實例時，前者都會注入進來：

AppServiceProvider.php

這使得使用配置或環(huán)境變量來控制日志記錄功能的激活或停用更為方便：

AppServiceProvider.php

使用這個方法似乎會需要很多的類。當然，用戶注冊僅僅是一個簡單的例子，旨在保證代碼的簡短清晰。一旦項目的復雜度開始增長，動作類的真正的價值就越來越明顯，因為你清晰的知道代碼所在及其界定。

小巧而單一的邏輯域能夠防止代碼重復并提高代碼的可重用性，保持穩(wěn)定。

易于針對各種場景進行獨立測試。

富有意義的命名在大型項目中更容易閱讀。

易于裝飾。

整個項目的一致性：防止代碼分布在 Controllers、Models 等。

當然，這個方法是基于我過去幾年使用 Laravel 的一些經(jīng)驗和我在一些項目中的實踐。這對我真的很有用，現(xiàn)在我甚至在一些中小型項目中使用。

如果你有不同的方法，我非常期待讀一讀。

更多現(xiàn)代化 PHP 知識，請前往 Laravel / PHP 知識社區(qū)