关于php:『转载』Laravel-中大型项目架构

初学者学习 Laravel 时候两种，一种是乖乖的将程式填入 MVC 架构內，导致 controller 与 model 异样的瘦小，日后一样很难保护；一种是经常不晓得程式改写在哪一个 class 內而犹豫不決，毕竟传统 PHP 都是一个页面一个档案。本文整顿出适宜 Laravel 的中大型项目架构，兼具容易保护、容易裁减与容易重复使用的特点，并且容易测试。

一个我的项目只有 MVC 是不够的，咱们须要更残缺的我的项目架构。

## 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 架构还在，由与 SOLID 的繁多职责原則与依赖反转准则:

咱们将资料库逻辑从 model 分离出来，由 repository 辅助 model，将 model 依赖注入进 repository。
咱们将商业逻辑从 controller 分离出来，由 service 辅助 controller，将 service 依赖注入进 controller。
我們将显示逻辑从 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。