🔥码云GVP开源项目 12k star Uniapp+ElementUI 功能强大 支持多语言、二开方便! 广告
## 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