初学者学习Laravel分两种方式。一是乖乖把程序塞进MVC架构，导致controller和model异常庞大，以后也很难维护；犹豫是因为不知道程序改写在哪个类，毕竟传统的PHP是一页一个文件。本文梳理了适合Laravel的中大型项目架构，易于维护，易于扩展和复用，易于测试。一个项目只有MVC是不够的，我们需要一个更完整的项目架构。##Controller太臃肿受RoR的影响，初学者往往认为MVC架构就是模型、视图、控制器：模型就是数据库。Controller负责与HTTP交互，调用模型和视图。视图是HTML。如果按照这个定义，下面的需求在哪里改写？发送电子邮件，使用外部API。用PHP编写的逻辑。根据需要转换显示格式。是否根据需要显示某些数据。根据需要显示不同的数据。其中1、2属于业务逻辑，3、4、5属于展示逻辑。按照普通人对MVC的定义，模型就是数据库，视图就是HTML。以上需求不能写在model和view中，只能勉强写在controller中。因此，初学者开始在控制器中编写大量的程序，导致控制器变得过于庞大，难以维护。模型太臃肿。既然逻辑都写在controller里面，不方便维护，那为什么不把所有的逻辑都写在model里面呢？当您将逻辑从控制器移至模型时，尽管控制器变得更薄，但模型变得更胖。模型本来代表的是数据库，现在还要负责业务逻辑和展示逻辑，结果就更糟了。模型是否代表数据库？就当它是一个Eloquent类吧，数据库逻辑应该写在repository里，这就是为什么Laravel5中没有models目录，而Eloquent类只是放在应用程序的根目录下。大中型项目结构应该如何转变？不要将我们的思维局限于MVC:Model:仅作为Eloquent类。Repository:辅助模型，处理数据库逻辑，然后注入服务。Service：辅助controller，处理业务逻辑，然后注入controller。控制器：接收HTTP请求并调用其他服务。Presenter：处理显示逻辑并将其注入到视图中。View:使用blade将数据绑定到HTML。在上面的架构中，我们可以发现MVC架构依然存在，基于SOLID的单一职责原则和依赖倒置原则：我们将数据库逻辑与模型分离，存储库辅助模型将模型依赖注入到存储库。我们将业务逻辑从控制器中分离出来，用服务来辅助控制器，在控制器中注入服务依赖。我们将显示逻辑从视图中分离出来，用Presenter辅助视图，并将Presenter依赖注入到视图中。创建目录在app目录下创建Repositories、Services和Presenters目录。不要害怕创建目录！！不要害怕创建Laravel默认目录以外的其他目录。根据SOLID的单一职责原则，一个类的功能越多，它的职责也就越多，所以越违反单一职责原则，所以你应该把你的程序分成更小的部分，每个部分都有自己的功能，而不是一个类功能覆盖山海，也就是所谓的万能类，所以整个解决方案不应该只有MVC的三部分，放手根据自己的需要创建一个合适的目录，并设置把合适的类放在这个目录下，只要我们的类有命名空间就可以帮我们分类。由于Repository篇幅较长，将repository单独成一篇专门的文章进行讨论。请参考如何使用Repository模式？服务由于服务篇幅较长，服务单独成一篇专文讨论。请参考如何使用服务模式？主持人。由于Presenter的篇幅，Presenter单独成一篇文章，本文的讨论请参考如何使用Presenter模式？单元测试由于模型、视图和控制器的依赖对象已经被拆解，并且使用了依赖注入，因此可以对每一部分单独进行单元测试。要测试服务，可以模拟存储库，也可以模拟其他服务。Presenter还可以独立运行单元测试来模拟其他服务。没有必要运行验收测试来测试显示逻辑。结束语本文中提到的架构仅仅是个开始。您可以根据实际需要添加更多的目录和类。当你发现你的MVC违反了SOLID原则时，大胆地将类从MVC中拆解重构，然后按照以下方法：新建一个类或接口。将依赖对象的依赖注入到类中。处理他在课堂上的职责。将类或接口注入控制器或视图。
