前言

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

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

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

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

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

避免神類的坑

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

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

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

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

介紹單動作類

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

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

• 一個動作類，應該有一個能夠說明其功能的名字，比如：CreateOrder, ConfirmCheckout, DeleteProduct, AddProductToCart等。
• 它應該有且只有一個公共方法，作為 API 。理想的情況下，應該是相同的方法名，像 handle() 或者 execute() 。如果需要對我們的動作類實現某種適配器模式，這是非常方便的。
• 它必須對請求和響應不可知。它不處理請求，也不發送響應。這樣的職責應該由控制器來承擔。
• 它可以依賴其它的動作類。
• 如果有任何事情阻止它執行和/或返回期望的值，那么它必須通過拋出一個 Exception 來強制執行相關的業務邏輯，并且讓調用者（或者 Laravel 的 ExceptionHandler ）來承擔如何呈現/響應異常的責任。

創建我們的 CreateUser 動作類

現在，讓我們看看前面的例子，并用一個單動作類來重構它，我們將命名為 CreateUser 。

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

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

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

動作類的嵌套

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

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

動作類的裝飾

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

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

AppServiceProvider.php

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

AppServiceProvider.php

總結

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

使用單動作類的好處：

• 小巧而單一的邏輯域能夠防止代碼重復并提高代碼的可重用性，保持穩定。
• 易于針對各種場景進行獨立測試。
• 富有意義的命名在大型項目中更容易閱讀。
• 易于裝飾。
• 整個項目的一致性：防止代碼分布在 Controllers、Models 等。

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

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

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。