前言

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

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

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

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

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

避免神類的坑

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

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

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

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

介紹單動作類

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

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

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

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

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

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

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

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

動作類的嵌套

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

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

動作類的裝飾

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

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

AppServiceProvider.php

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

AppServiceProvider.php

總結(jié)

使用這個方法似乎會需要很多的類。當(dāng)然，用戶注冊僅僅是一個簡單的例子，旨在保證代碼的簡短清晰。一旦項(xiàng)目的復(fù)雜度開始增長，動作類的真正的價(jià)值就越來越明顯，因?yàn)槟闱逦闹来a所在及其界定。

使用單動作類的好處：

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

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

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

總結(jié)

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

最新評論