本篇文章给大家带来的内容是关于PHP框架中MVC架构的分析（附示例），有一定的参考价值，有需要的朋友可以参考一下，希望对你有所帮助。

在说 MVC 架构之前，先说说PHP框架吧。很多很多学完PHP语言的人，面对的就是PHP各种各样的框架。什么TP啊、Yii啊、CI啊，还有很流行的laravel啊等等。

他们的大部分都会说自己是基于 MVC 的架构，接着你得试着去理解 MVC 的逻辑，并尝试着用这样的逻辑去构建一个网站，然后会说 MVC 真香～

面试

很多 PHP 的面试中，可能会问关于 MVC 的问题，比如 MVC 到底是什么意思，怎样理解这种架构。然而很多人的理解是 model 是模型，他对应着数据库中的表结构；view 对应着页面，用于展示；controller 主要用来写各种逻辑，关联数据和页面的显示。

以上回答基本上没有问题，但一个网站的结构真的有那么简单么？显然不是

设计

在说之前，首先让我们了解一下设计模式的一种：中介者模式。一个形象的理解就是：港行插头和国行插头的转接头。

在 MVC 架构中 controller 就是这个转接头。它只负责把 model 中的数据转接给 view，对于访问者来说，他们是看不到 model 中保存的真实数据的。从另外一个角度来说，这种中介者模式可以很好的将两层数据进行友好的通信。

爬坑

这种模式真的那么好么？随着业务逻辑的越来越复杂，会发现 controller 中的代码越来越多，甚至自己都不愿去调整和优化冗余代码。

但从宏观上来说，网站无非是请求多一些，表单多一些，页面多一些啊，其他也没什么了，为什么会这样呢？

没错，就是因为这样或那样的东西比较多，导致 controller 中每个方法都很长，那么能想到的解决方法就是拆分。

如果用过 yii 框架，那么你会知道最简单的办法是加一个请求form层，代码如下：

1. class AuthController { 
2.  
3.     public function login() { 
4.  
5.         $FLogin = new loginForm(); 
6.  
7.         $FLogin->save(); 
8.  
9.     } 
10.  
11. } 
12.  
13.  
14.  
15. // 一般在独立的文件夹中 
16.  
17. class loginForm { 
18.  
19.     public function __construct() { 
20.  
21.         $post = $_POST; 
22.  
23.     } 
24.  
25.      //phpfensi.com 
26.  
27.     public function save() { 
28.  
29.     } 
30.  
31. } 

以上的就是解决 controller 中 form 表单的问题，这个问题基本上能缓解很多代码问题。

发散

从解决 form 层来看，其实有很多类似的问题都能解决。我们知道前端有个叫做 vue.js 的框架，它里面提到一个概念叫做 MVVM 模型。

其实在展现复杂页面的时候，后端在对外输出数据时，完全也可以采用这玩意进行数据输出。至于如何建立这样的一个模型，那就具体得看业务逻辑了。

这里简单拿用户中心举个例子，因为往往这里不仅仅需要一个表的数据：

1. class AuthController { 
2.  
3.     public function userCenterAction() { 
4.  
5.         return new userVM(); 
6.  
7.     } 
8.  
9. } 
10.  
11. class userVM { 
12.  
13.     public $user; 
14.  
15.     public $orders; 
16.  
17.     public $other; 
18.  
19.     public function __construct() { 
20.  
21.         $this->user = $this->getUser(); 
22.  
23.         $this->orders = $this->getOrders(); 
24.  
25.         $this->handle(); 
26.  
27.     } 
28.  
29.     private function getUser() { 
30.  
31.         return NULL; 
32.  
33.     } 
34.  
35.     private function getOrders() { 
36.  
37.         return NULL; 
38.  
39.     } 
40.  
41.     private function handle() { 
42.  
43.     } 
44.  
45. } 

以上代码中，有个 VM 层，可以将相关获取数据的代码放在各自的方法中，然后在 handle 方法中自由组合。这样在 controller 中的代码也非常便于管理。

再想想，有没有可以封装的其他层呢？其实是有的，比如 request 层，还有经常被框架封装好的 validate 层，还有 laravel 中比较流行的 Middleware 层等等。只能说系统越复杂，层越多。

每个复杂系统的背后都蕴含着高级开发工程师和架构师的设计思路。以上说那么多，不知道读者能否理解这些东西，就拿以上代码来说，里面就蕴含着另一种设计模式：建造者模式。

总结:

代码写多了，也就知道其中蕴含的道理了。当一个新框架诞生后，关注点从学习这个框架，慢慢变成了这个框架是如何设计的，解决什么样的问题。哪些地方用了比较好的技术和方法，从中能收获到什么。一些地方的设计思路是什么样的，有么有更好的设计，为何我能想到，对方想不到呢，是不是我遗漏了什么。

前几年使用过各种 PHP 框架，小到 CI，大到 Symfony。不用那么多框架，也体会不到这些东西。学习编程其实和英语一样，没什么捷径可以走。

多写，多想，多练......

Tags: PHP框架 MVC架构

分享到：