MVC架构 · php笔记

## 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&timestamp=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