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

Controller过于肥大

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

Model就是数据库。
Controller负责与HTTP沟通，调用model与view。
View就是HTML。

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

发送Email，使用外部API。
使用PHP写的逻辑。
依需求将显示格式作转换。
依需求是否显示某些数据。
依需求显示不同数据。

其中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将数据binding到HTML。

其中蓝色为原本的MVC，而紫色为本文要介绍的的重点：Repository模式，Service模式与Presenter模式。
箭头表示物件依赖注入的方向。
我们可以发现MVC构架还在，由于SOLID的单一职责原则与依赖反转原则：