Laravel 中大型项目架构

Laravel 的中大型项目架构

 一个项目只有 MVC 是不够的，我们需要更完整的项目架构

1. Controller 过于臃肿
2. Model 过于臃肿
3. 中大型项目架构
   1. 建立目录
   2. Repository
   3. Service
   4. Presenter
4. 单元测试
5. Conclusion

初学者学习 Laravel 时分两种，一种是乖乖的将程式填入 MVC 架构內，导致 controller 与 model 异常的肥大，日后一样很难维护；一种是常常不知道程式改写在哪一个 class 內而犹豫不決，毕竟传统 PHP 都是一个页面一个档案。本文整理出最适合 Laravel 的中大型项目架构，兼具容易维护、容易扩充与容易重复使用的特点，并且容易测试。

Controller 过于臃肿

---

受RoR的影响，初学者常认为 MVC 架构就是 model, view, controller :

• Model 就是资料库。
• Controller 负责与 HTTP 交互，调用 model 与 view。
• View 就是 HTML。

假如依照这个定义，以下这些需求改写在哪里呢？

1. 发送 Email，使用外部 API。
2. 使用 PHP 写的逻辑。
3. 依需求将显示格式作转换。
4. 依需求是否显示某些资料。
5. 依需求显示不同资料。

其中 1, 2 属于商业逻辑，而 3, 4, 5 属于显示逻辑，若依照一般人对 MVC 的定义，model 是资料库，而 view 又是 HTML，以上这些需求都不能写在 model 与 view，只能勉强写在 controller。

因此初学者开始将大量程式写在 controller，造成 controller 的肥大难以维护。

Model 过于臃肿

---

 既然逻辑写在 controller 不方便维护，那我将逻辑都写在 model 就好了？

当你将逻辑从 controller 搬到 model 后，虽然 controller 表瘦了，但却肥了 model，model 从原本代表资料库，現在变成还要负责商业逻辑与显示逻辑，结果更慘。

Model 代表资料库吗？把它想成是 Eloquent class就好，资料库逻辑应该写在 repository 里，这也是为什么 Laravel 5 已经沒有 models目录，Eloquent class 仅仅是放在 app 根目录下而已。

中大型项目架构

---

那我们改怎么写呢？別将我们的思维局限在 MVC 內 :

1. Model : 仅当成 Eloquent class。
2. Repository : 辅助 model，处理资料库逻辑，然后注入到 service。
3. Service : 辅助 controller，处理业务逻辑，然後注入到 controller。
4. Controller : 接收 HTTP request，调用其他 service。
5. Presenter : 处理显示逻辑，然后注入到 view。
6. View : 使用 blade 将资料 绑定 到 HTML。

其中蓝色为原本的 MVC，而紫色为本文要介绍的的重点 : Repository 模式，Service 模式与 Presenter 模式。

箭头表示物件依赖注入的方向。11關於依賴注入，詳細請參考深入探討依賴注入

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

1. 我們將資料庫邏輯從 model 分離出來，由 repository 輔助 model，將 model 依賴注入進 repository。
2. 我們將商業邏輯從 controller 分離出來，由 service 輔助 controller，將 service 依賴注入進 controller。
3. 我們將顯示邏輯從 view 分離出來，由 presenter 輔助 view，將 presenter 依賴注入進 view。

建立目錄

在 app 目錄下建立 Repositories，Services 與 Presenters 目錄。
 

 別害怕建立目錄！！

別害怕在 Laravel 預設目錄以外建立的其他目錄，根據 SOLID 的單一職責原則，class 功能越多，責任也越多，因此越違反單一職責原則，所以你應該將你的程式分割成更小的部分，每個部分都有它專屬的功能，而不是一個 class 功能包山包海，也就是所謂的萬能類別，所以整個專案不應該只有 MVC 三個部分，放手根據你的需求建立適當的目錄，並將適當的 class 放到該目錄下，只要我們的 class 有 namespace 幫我們分類即可。

Repository

由於篇幅的關係，將 repository 獨立成專文討論，請參考如何使用 Repository 模式?

Service

由於篇幅的關係，將 service 獨立成專文討論，請參考如何使用 Service 模式?

Presenter

由於篇幅的關係，將 presenter 獨立成專文討論，請參考如何使用 Presenter 模式?

單元測試

---

由於現在 model、view、controller 的相依物件都已經拆開，也都使用依賴注入，因此每個部分都可以單獨的做單元測試，如要測試 service，就將 repository 加以 mock，也可以將其他 service 加以 mock。

Presenter 也可以單獨跑單元測試，將其他 service 加以 mock，不一定要跑驗收測試才能測顯示邏輯。

Conclusion

---

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

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

• 最後搭配單元測試，測試重構後的架構是否與原來的需求結果相同。