Laravel 对中大型项目的架构设计

初学laravel时分两种 一种是乖乖的将程序填入MVC架构中 导致controller 和 model异常的臃肿 controller对model高度依赖导致项目在壮大时难以维护. 另一种是不知道程序该写在哪一个class内 毕竟传统 php都是一页一个程序.这里整理出最适合laravel的大型架构,兼具易维护 易扩充 容易重复使用的特点。

受RoR的影响，传统的认为 MVC 就是 model, view, controller :

• Model 就是数据资料库。
• Controller负责调用 model 和view。
• View 就是 HTML。

假如按照传统的MVC概念 那么如下的需求应该怎么写呢？

1. 发送 短信验证码，使用外部 API。
2. 使用php调用api完成业务逻辑。
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架构其实还在 由于SOLID的单一职责与 依赖反转原则

• 我们将数据从model 分离出來，由 repository 辅助 model，将 model 依赖注入进 repository。
• 我们将业务逻辑從 controller 分离出來，由 service 辅助 controller，将 service 依赖注入进 controller。
• 我们将显示逻辑 view 分离出來，由 presenter 辅助 view，將 presenter 依賴注入进 view。

单元测试

---

由于现在将 model、view、controller 的相依物件都已经拆开，也都使用依赖，因此每个部分都可以单独的做单元测试，如要测试 service，就将 repository 加以 mock，也可以将其他 service 加以 mock。

Presenter 也可以单独的进行单元测试，将其他 service 加以 mock。

Conclusion

---

• 本文谈到的架构只是开始，你可以依照实际需求增加更多的目录和class，当你发现违法 SOLID原则，就大膽的將 class 从MVC拆开重构

 

 

原本地址 http://www.xuyuanchang.site/archives/98.html
欢迎关注我的个人博客 http://www.xuyuanchang.site
转载请注明地址