前言说MVC架构之前，先说说PHP框架。很多学过PHP语言的人都会面对各种各样的PHP框架。什么TP，Yii，CI，还有现在很流行的laravel等等。他们大多会说他们是基于MVC架构的，然后你要试着去理解MVC的逻辑，并尝试用这个逻辑来建网站，然后他们就会说MVC真香~在很多PHP的面试，你可能会问到关于MVC的问题，比如MVC到底是什么意思，如何理解这个架构。但是很多人理解model就是模型，对应数据库中的表结构；view对应页面，用于展示；controller主要用来编写各种逻辑，关联数据，显示页面。以上回答基本没有问题，但是一个网站的结构真的那么简单吗？显然不是设计在讲它之前，我们先来了解一类设计模式：中介模式。形象理解为：港行插头和国行插头的转接头。在MVC架构中，控制器就是适配器。它只负责将模型中的数据传输到视图中。对于访问者来说，他们看不到存储在模型中的真实数据。从另一个角度来看，这种中介模型可以很好地友好沟通两层数据。爬坑模式真的有那么好吗？随着业务逻辑越来越复杂，你会发现controller中的代码越来越多，甚至不愿意对冗余代码进行调整和优化。但是从宏观上看，网站无非就是请求多，表单多，页面多，别的不说。为什么会这样？没错，因为这样那样的东西很多，controller中的每个方法都很长，所以能想到的方案就是拆分。如果你用过yii框架，那么你就会知道最简单的方法就是添加一个请求表单层，代码如下：classAuthController{publicfunctionlogin(){$FLogin=newloginForm();$FLogin->保存();}}//一般在单独的文件夹中classloginForm{publicfunction__construct(){$post=$_POST;}publicfunctionsave(){}}以上就是解决controller中form表单的问题，这个问题基本上可以缓解很多代码问题。Divergence从解决表单层的角度来看，其实还有很多类似的问题可以解决。我们知道前端有个框架叫vue.js，里面提到了一个概念叫MVVM模型。其实在显示复杂页面的时候，后台对外输出数据的时候，也可以用这个东西来进行数据输出。至于如何构建这样的模型，则取决于业务逻辑。这里简单以用户中心为例，因为这里经常需要不止一张数据表：classAuthController{publicfunctionuserCenterAction(){returnnewuserVM();}}classuserVM{public$user;公共$订单；公共$其他；公共函数__construct(){$this->user=$this->getUser();$this->orders=$this->getOrders();$this->handle();}私有函数getUser(){返回NULL；}私有函数getOrders(){返回NULL；}privatefunctionhandle(){}}在上面的代码中，有一个VM层，可以把相关的数据获取代码放在各自的方法中，然后在handle方法中自由组合。这样controller中的代码也非常好管理。再想想，还有其他层可以封装吗？其实还有，比如request层，framework经常封装的validate层，还有laravel中比较流行的Middleware层等等，只能说系统越复杂层越多。每一个复杂系统的背后，都隐藏着资深开发工程师和架构师的设计思想。上面说了这么多，不知道读者能不能看懂这些。以上面的代码为例，其中包含了另一种设计模式：建造者模式。总结一下，代码写多了，就知道背后的道理了。当一个新的框架诞生时，关注点逐渐从学习框架转移到框架是如何设计的，它解决了什么样的问题。更好的技术和方法用在哪里，可以从中获得什么。有些地方的设计思路是什么？有更好的设计吗？为什么我能想到，对方却想不到？有什么我想念的吗？在过去的几年里，我使用了各种PHP框架，从CI到Symfony。没有那么多框架，我无法实现这些东西。学编程其实和学英语一样，没有捷径可走。多写，多想，多练……以上
