您好,登錄后才能下訂單哦!
這篇文章將為大家詳細講解有關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
關于“Laravel如何使用動作類”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,使各位可以學到更多知識,如果覺得文章不錯,請把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。