初学laravel时分两种 一种是乖乖的将程序填入MVC架构中 导致controller 和 model异常的臃肿controller对model高度依赖导致项目在壮大时难以维护. 另一种是不知道程序该写在哪一个class内 毕竟传统 php都是一页一个程序.这里整理出最适合laravel的大型架构,兼具易维护 易扩充 容易重复使用的特点。
受RoR的影响，传统的认为 MVC 就是model,view,controller:
Model 就是数据资料库。Controller负责调用 model 和view。View 就是 HTML。
假如按照传统的MVC概念 那么如下的需求应该怎么写呢？
发送 短信验证码，使用外部 API。使用php调用api完成业务逻辑。依照需求将格式显示。依需求是进行对转换的格式进行内容筛选。依需求显示不同資料。
其中 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 內 :
Model:仅仅是一个Eloquent class。Repository: 辅助 model，处理数据逻辑，然后注入到 service。Service: 輔助 controller，處理业务逻辑，然後注入到 controller。Controller: 接收 HTTP request，调用其他 service。Presenter: 处理显示，然后注入到 view。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
转载请注明地址
