Laravel 程序架構設計思路：使用動做類

當咱們談論到應用程序的架構的時候，常常會問到一個經典的問題，那就是「這段代碼應該放在哪裏比較好」。 由於 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 的一些經驗和我在一些項目中的實踐。這對我真的頗有用，如今我甚至在一些中小型項目中使用。

若是你有不一樣的方法，我很是期待讀一讀。

更多現代化 PHP 知識，請前往 Laravel / PHP 知識社區