一、MVC架構(中大型專案) - amattsuyolo/cham GitHub Wiki

參考文章:

前言

自己開發php過程中從無框架開始，對於新手從第一行閱讀到最後一行便能理解專案某種程度是件非常美好的事，然而考量到程式碼的復用與維護容易 ，或是潮潮的說為了符合:"物件導向程式設計基本原則 - SOLID"，大部分的網站專案都會走向所謂的MVC或更直白的說法:"多層次架構"，自己在走入 MVC開發後不久就對於MVC架構有著模糊與不對稱的感受，以下是自己閱覽大神們文章的重點萃取與專案所參照的部分。

MVC開始(下列大量引述參考文章內容)
首先得要了解MVC是三個極度不對稱的存在。

  • V: 負責呈現UI
  • C: 負責與 HTTP 溝通，調用 model 與 view。
  • M: 負責資料庫

C幾乎是你的整個application。

參考上面規範，下面功能需要放在哪裡?

  1. 發送 Email，使用外部 API。
  2. 使用 PHP 寫的邏輯。
  3. 依需求將顯示格式作轉換。
  4. 依需求是否顯示某些資料。
  5. 依需求顯示不同資料。

其中 1, 2 屬於商業邏輯，而 3, 4, 5 屬於顯示邏輯，若依照一般人對 MVC 的定義，model 是資料庫，而 view 又是 HTML，以上這些需求都不能寫在 model 與 view，只能勉強寫在 controller。

初學者將大量程式寫在 controller，造成 controller 的肥大難以維護。 既然如此改為以下架構如何?

  • V: 負責呈現UI
  • C: 負責接受request、請M處理、回傳response
  • M: 負責全部的business logic

M幾乎是你的整個application。model 從原本代表資料庫，現在變成還要負擔商業邏輯與顯示邏輯，變得更糟糕了

自己在GOOGLE的結果汪洋中大量的搜尋，就自己的經驗感受下列參考(Laravel 的中大型專案架構:)會是一個相當優秀的架構:

  • Model(Entity) : 僅當成 Eloquent class。
  • Repository : 輔助 model，處理資料庫邏輯，然後注入到 service。
  • Service : 輔助 controller，處理商業邏輯，然後注入到 controller。
  • Controller : 接收 HTTP request，調用其他 service。
  • Presenter : 處理顯示邏輯，然後注入到 view。
  • View : 使用 blade 將資料 binding 到 HTML。

箭頭表示物件依賴注入的方向 關於依賴注入 第九章會做介紹

我們可以發現 MVC 架構還在，由於 SOLID 的單一職責原則與依賴反轉原則 :

  • 我們將資料庫邏輯從 model 分離出來，由 repository 輔助 model，將 model 依賴注入進 repository。
  • 我們將商業邏輯從 controller 分離出來，由 service 輔助 controller，將 service 依賴注入進 controller。
  • 我們將顯示邏輯從 view 分離出來，由 presenter 輔助 view，將 presenter 依賴注入進 view。 以下是專案架構示意圖 可以直接參照程式碼

結論與實作步驟

本文談到的架構只是開始，你可以依照實際需求增加更多的目錄與 class，當你發現你的 MVC 違反 SOLID 原則時，就大膽的將 class 從 MVC 拆開重構，然後依照以下手法 :

  1. 建立新的 class 或 interface。
  2. 將相依物件依賴注入到 class。
  3. 在 class 內處理他的職責。
  4. 將 class 或 interface 注入到 controller 或 view。