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

Caicloud 發布于2019-07-01 10:05 / 2493人閱讀

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

當我們談論到應用程序的架構的時候，經常會問到一個經典的問題，那就是“這段代碼應該放在哪里比較好”。因為 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 知識社區

云服務器 GPU云服務器設計思路 java問題設計思路架構師架構設計架構架構設計

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/28789.html

Laravel入門及實踐，快速上手ThinkSNS+二次開發

摘要：在中，提示符可能是。框架使用來執行安裝及管理依賴。為了能訪問網頁，要啟動程序服務器。在大多數類系統中，包括，命令行提示符是符號。這兩個操作分別對應于的和，即創建和讀取。首個表單要在模板中編寫表單，可以使用表單構造器。【摘要】自從ThinkSNS+不使用ThinkPHP框架而使用Laravel框架之后，很多人都說技術門檻抬高了，其實你與TS+的距離僅僅只是學習一個新框架而已，所以，我們...

glumes 2019-06-28 13:37 評論0 收藏0
跟控制器說再見吧，從今天開始使用請求處理器（Request Handlers）范式

摘要：請求處理器可以理解為僅包含單個動作的控制器，能夠使請求到響應的流程更加清晰明確。一個好的使用例子是路由的請求處理在和框架中。控制器的動作被分為多個獨立的請求處理器類，分別負責響應單一的動作。您是否應當使用請求處理器替換所有控制器可能不是。在過去幾年中， PHP 開發環境發生了很大的變化。我們開始使用更多更好的設計模式，比如 DRY 和 SOLID) 設計模式原則。但為什么我們仍然在...

brianway 2019-07-01 11:08 評論0 收藏0
Laravel核心解讀--完結篇

摘要：過去一年時間寫了多篇文章來探討了我認為的框架最核心部分的設計思路代碼實現。為了大家閱讀方便，我把這些源碼學習的文章匯總到這里。數據庫算法和數據結構這些都是編程的內功，只有內功深厚了才能解決遇到的復雜問題。過去一年時間寫了20多篇文章來探討了我認為的Larave框架最核心部分的設計思路、代碼實現。通過更新文章自己在軟件設計、文字表達方面都有所提高，在剛開始決定寫Laravel源碼分析地...

laoLiueizo 2019-07-01 11:21 評論0 收藏0