php項目目錄的合理劃分和Pipeline 組件的使用場景

php項目目錄的合理劃分和Pipeline 組件的使用場景

這是一篇遲到的文章，很早以前就一直想寫了，但是經驗不足有些地方理解的不透側，固然，如今這篇文章可能也是淺嘗輒止，但願不要噴我

開篇

首先，能夠先導讀一下以下這篇文章，有助於提高一下代碼質量

Laravel 的十八個最佳實踐

單一職責原則

通俗點介紹則是，一個功能爲一個功能所作事情。
例如，咱們須要獲取用戶信息，那簡而言之，編寫的 getUserInfo 則只用它來作一件東西。
固然，這只是一個方法，若是一個類呢，咱們須要怎麼來定義

現在你們遵循的大多數是 mvc 規範，如今的開發流程下，大概v，也就是視圖層早已經消失殆盡

mc的關係如何處理呢，我建議大概是以下幾種

-app
--Model  // 模型層
--Controller // 控制器層
--Traits 
--Stores // 處理類
--Tools // 工具類
--Routers // 擴展路由

模型和控制器就不須要多說了

• Traits

  這個名詞的解釋,Trait 就很少書了，可見官方手冊 : https://www.php.net/manual/zh...

  這裏主要存放一些複用的公共函數方法，例如獲取器，驗證器等等，

• Stores

用來存放模型或者控制器不方便寫的一些代碼，例如返回一個商品信息，須要針對商品清單從其餘數據庫或則數據表進行補全完整的信息
例如，購買人次，成交額等等，這個時候，這些東西既不適合交給控制器也不適合交給模型層

• Tools

工具類，這裏存放一些工具方法，例如處理某個數據集的公用或者某個組件功能須要使用的方法
常見的有響應方法，打日誌的方法等等

• Routers

路由擴展文件，這個文件的意義就在於，當系統或者功能龐大起來以後，路由將會變得很是很差管理，基本上在後臺管理中，一個功能可能就產生5個左右路由

這個時候就須要其將路由文件拆分開來

以上的操做，固然不能一律而論，應當適當的針對業務場景進行處理，例如簡單的一個後臺，管理用戶的功能就無需如此繁雜。當功能愈來愈多而很差管理的時候才能適當的發揮它的最大做用

重要篇

Pipeline 組件 是什麼

參考文章:
【單篇】Laravel Pipeline 組件的實現原理

這是一個很是有趣的功能，你們應該或多或少的使用過中間件，是否是歷來沒有過去了解中間件呢

其實，中間件背後的邏輯及其實現也就是 Pipeline 的簡化版

中文寓意是通道的意思

使用場景

上代碼:

如上，咱們發現，第一張圖咱們代碼很是很是少，最後一張圖，返回的數據字段很是很是多，而查詢語句也並無查詢多少東西

使用場景大概以下

有一批商品信息，咱們只知道他的商戶id和商品id (product表)
由此，咱們須要給前端返回
(訂單成交額 order表)
(分類信息 tag表)
(成交用戶屬性信息 user表)
(優惠信息 coupone表)

這個時候，按照以往的邏輯，咱們有幾種解決方案

• foreach
• foreach + 類處理

大概第二種方法用的人會最多，循環商品信息，當if須要成交額當時候就去成交額的表中查詢，而後給補齊上

第一種方法就忽略吧，都是寫在一個方法裏面來foreach， 極度不推薦

這個時候就 Pipeline 它上場了，經過傳導數據給它，在 Pipeline 的dispatcher中添加類
例如補齊訂單成交額，則能夠添加 Order::Class 等等

最大的好處，既是，將功能與功能之間耦合開來，從而即使後續咱們須要針對訂單成交額的代碼邏輯進行修復，也不須要去修改設計到這一整塊邏輯的代碼

好處

• 可讀性強
• 符合單一職責原則
• 耦合度低

php學習交流羣 : 735713840