前言

當我們談論到應用程序的架構的時候，經(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)用這個服務類”。是的，沒錯，問題是我們應該怎么設計 service 類？是創(chuàng)建一個 UserService 類來實現(xià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)和模糊的服務術語，來了解一下我們的新動作類，并定義它們是什么以及它們可以做什么。

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

創(chuàng)建我們的 CreateUser 動作類

現(xiàn)在，讓我們看看前面的例子，并用一個單動作類來重構它，我們將命名為 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)在，假設我們想在日志中記錄每一個新注冊的用戶。我們可以將代碼寫在動作類內(nèi)部，也可以使用裝飾者模式。

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

AppServiceProvider.php

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

AppServiceProvider.php

總結(jié)

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

使用單動作類的好處：

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

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

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

總結(jié)

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