php里的mvc架构图,MVC架构

## MVC架构

> **控制器** > **逻辑层/服务层** > **模型层**

**控制器：** 承接前端请求，好的设计应该是“瘦”控制器。也可以被其它控制器调用。

**逻辑层：** 业务逻辑代码主要在逻辑层，“胖”逻辑层。可以被控制器直接调用，也可被其他逻辑层或服务层调用。(业务逻辑就是跟业务相关的逻辑，其中很重要的就是sql操作，这些sql是具有意义的，业务最终会落地到sql上去体现，其意义就是表现业务逻辑——或者说sql其实就是逻辑sql。)

**服务层：** 和逻辑层类似，可以被控制器直接调用，也可被逻辑层或其他服务层调用。

**模型层：** 数据操作层，被服务层或逻辑层调用，甚至简单的被控制器直接调用(不推荐)。定义数据结构，验证规则。提供DB操作方法。任何一张数据表都是一个模型(每张表的每个字段决定了数据的格式，规则)，逻辑层需要保存更改数据时调用各个模型完成ORM操作持久化到数据库。

>[danger] 关键的地方就在于模型层和Db层的结合，数据模型层在操作时自己会连接数据库执行sql(惰性连接数据库)，也会自己断开连接，模型层无需关系Db层的情况，对模型层完全屏蔽了Db层的复杂性，操作模型层感觉不到sql。

(Db层其实就没有了，被抽象到模型中去了(模型也是利用Db类执行sql)，模型隐藏了Db、sql操作的细节，当然Db也是可以单独灵活调用的，此时Db就相当于一个Db操作工具库了，有点类似于前端中的jQuery的身份了，不过还是建议都定义模型类来进行抽象操作。不过在快速开发初期为了方便也是可以直接Db类的，方便，不过要知道这样做并不是一个好习惯。)

> 任何一个方法，不论什么层，只需要关注，它接收什么参数，内部做什么操作，返回什么数据。我们的所有代码几乎都是在做这样的事情。

**补充：**

模型层不要有任何的业务逻辑，模型层只提供数据的定义，和Db(实际上模型层和Db层是紧密相连的，模型层对外屏蔽了Db层的)，模型层被逻辑层调用，模型层只能被调用，不能调用别人，一个业务逻辑可能包含多个模型，多条sql，所以模型层必须单纯，只提供数据定义就可以了，剩下的交给逻辑层。控制器起一个调度作用，理论上控制器一上来全部调用逻辑层，甚至每个控制器都有一一对应的逻辑层都可以，但是对于比较简单的请求，也可以不需要逻辑层，但是控制器中一定不要出现业务逻辑，特别是有sql的，控制器只能调用逻辑层和服务层，千万不要自己调用模型层来做事，所以控制器其实每个方法的代码量很少，大部分代码都在逻辑层和服务层，**业务逻辑主要就是sql操作**，切记sql只能出现在逻辑层和服务层中，大家各司其职，都保持单纯点，对外提供单一功能，这样系统就会更加可靠，便于维护。

以前的系统，很多业务逻辑都在模型层，比如给模型层定义各种各样的方法，模型层既有业务逻辑，又承担数据的定义和提供Db，这样太杂了，不利于维护。

**模型层用起来感觉像是使用Db一样。所以如非必要就不要去直接使用Db类。**

> 模块是数据和方法的集合。

* * * * *

### 扩展

[为什么我们要用函数式编程](https://www.toutiao.com/a6435902552059478273/?tt_from=weixin&utm_campaign=client_share×tamp=1515522953&app=news_article&utm_source=weixin&iid=22069500288&utm_medium=toutiao_android&wxshare_count=1)

> **简单来说，也就是当一个函数的输出不受外部环境影响，同时也不影响外部环境时，该函数就是纯函数。**(面向对象就不同了，方法的输出结果与运行环境的上下文有关。)

[面向对象圣经](http://mp.weixin.qq.com/s/DZyn2w6ci86qt73gIJjzqA)

[函数式编程圣经](http://mp.weixin.qq.com/s/0gErQ3tjDLZuD1bYOhi0mQ)

[左耳朵耗子：什么是函数式编程？](https://mp.weixin.qq.com/s/nh5qifdneF_Y3xOJBy_ipg)

> “所以代码在并行上根本不需要锁”：因为没有竞态资源。

[PHP 后端组织项目结构的思考](http://mp.weixin.qq.com/s?__biz=MjM5NTEwMTAwNg==&mid=2650211377&idx=2&sn=259beb5e5c59be2c059b506f290dd62a&chksm=befe041089898d0648c6a8123d24cc1d40d40c29fa0bc6da901eed49393123cacfdb24e29a33&scene=21#wechat_redirect)

[PHP设计模式系列：目录 - CSDN博客](http://blog.csdn.net/qq_32300363/article/details/71078666)

[【译】深入研究 Laravel 的依赖注入容器](https://mp.weixin.qq.com/s/yFjmrXAe9S45JqBAUgobhA)

[你真的理解了MVC, MVP, MVVM吗？](http://mp.weixin.qq.com/s/EzxfJLb5Hjxyw0_S5rThvg)

[教你在不使用框架的情况下也能写出现代化 PHP 代码](https://mp.weixin.qq.com/s/iQSmVPRwiqTADm1Ol4a6Eg)

[隔离 View 和 Model (Swift)](https://mp.weixin.qq.com/s/Mi3B8ysGCBT9LfYeo8HGKw)

[10 个常用的软件架构模式](https://mp.weixin.qq.com/s/PjHEpKqoMX-NdJF102xklw)

[为什么要用单例模式？](https://mp.weixin.qq.com/s/rQQTonFsesSk2E1Vtymh9Q)

[Web 框架的架构模式探讨](https://mp.weixin.qq.com/s/EAEDYl9a9MRFDeHj4RgPRA)

> 想象一下没有 MVC 架构模式，可能所有的 Web 框架必然的会实现一套几乎解决同样问题的方案，但是命名和文档却各不一样，当你去看一个新的框架文档的api 接口，从头到尾看完以后才恍然大悟，这不就是之前用的框架里面的 XXX 类似吗，这样的编程世界简直地狱。庆幸的是，得益于计算机科学家(码农)对问题和方案持续的抽象成模式，使得当前高度复杂的计算机科学也能得到合理分层和适配，大大简化了学习和沟通的成本。

[聊聊设计模式之工厂方法模式](https://mp.weixin.qq.com/s/UaVd9iGkOVR4JgYFhDxrQg)

[maven最佳实践之模块划分](https://mp.weixin.qq.com/s/ZMKrfwNilsJUre13eygtvg)

[为什么说 Java 程序员到了必须掌握 Spring Boot 的时候？](https://mp.weixin.qq.com/s/jwgsJnj0V21xAJnBsj_VvA)

> 在此引用 Python 的经典设计格言，格言来源于 Python 但不限于 Python。

>

> 美丽优于丑陋。

> 清楚优于含糊。

> **简单优于复杂。**

> 复杂优于繁琐。

> 平坦优于曲折。

> 宽松优于密集。

> 重要的是可读性。

> **特殊的案例不足以特殊到破坏规则。**

> **尽管实践可以打破真理。**

> **错误却不可置之不理。**

> **除非另有明确要求。**

> **面对模棱两可，拒绝猜测。**

> **总会有一个 —— 最好是只有一个 —— 显而易见的方式来明辨。**

> 哪怕这种方式在开始的时候可能并不明显。

> 现在有比没有好。

> 尽管没有经常好于现在。

> 如果如何实现很难被解释清楚，那么这个想法就是一个坏想法。

> 如果如何实现可以被很好的解释，那么这是一个好想法。

[责任链模式实现的三种方式](https://mp.weixin.qq.com/s/ZuOsksqLKCWBnALmO6ZkDg)

> 责任链模式不就违背了不能相互耦合的规则。相反责任链是为了解决耦合问题。

[PHP程序员如何理解IoC/DI - zhaoyi - SegmentFault 思否](https://segmentfault.com/a/1190000002411255)

[PHP程序员如何理解依赖注入容器(dependency injection container) - zhaoyi - SegmentFault 思否](https://segmentfault.com/a/1190000002424023)

[PHP中的服务容器与依赖注入的思想 - 逸梦 - SegmentFault 思否](https://segmentfault.com/a/1190000015449325)

[PHP容器--Pimple运行流程浅析 - 飞鸿影~ - 博客园](https://www.cnblogs.com/52fhy/p/7102083.html)

[Pimple - 一个简单的 PHP 依赖注入容器 - 小码农的打怪 - SegmentFault 思否](https://segmentfault.com/a/1190000014471794)

[使用 Laravel 服务容器的优势 - 个人文章 - SegmentFault 思否](https://segmentfault.com/a/1190000015463623)

使用了了laravel服务容器以后：

```php

/**

*发送邮件服务类

*/

class EmailService{

public function send(){

//todo 发送邮件方法

}

}

$this->app->bind('emailService', function ($app) {

// 这儿就是中间层，也就是实现解耦的地方了，后期可以灵活变动，而无需更新硬编码的部分

return new EmailService();

});

//如果任何地方要发邮件我们就复制下面这两行代码

// 调用部分，这儿就是硬编码了

$emailService = app('emailService');

$emailService->send();

```

还记得计算机的一切问题都可以通过封装来解决吗？

上面的模型其实最简单的三层模型：

服务(能力提供) > 中间层(解耦) > 调用处(执行动作)

* * * * *

last update：2018-2-14 18:15:31