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&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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值