MVC我一直理解错了？？

Question

我一直以为MVC的图解是下图：

视图和模型是不直接交互的，是通过控制器来协调的。

可是我最近看的文章里MVC是下面的图：

视图可以和模型直接交互的？难道我以前一直搞错了，而且做项目的时候也禁止视图与模型有直接交互的啊？

补充：

Answer 1

题主理解的不错，一般想到MVC就是这种模式： 用户在v层触发 然后请求c层 c层调用m层获取数据 c层再整合数据 最后c层调用v层展示 上面的这种MVC设计模式，应该是最初的MVC设计模式了。后来随着编程、设计模式的多元化，慢慢的在此基础上（M模型C控制器V视图）又增加了许多衍生版。 我理解的，MVC就是一个名词，或者一个代号，一种设计模式。但是三者之间具体要怎么关联，产生怎么样的联系，不是规定死的，还是看实际业务架构的。

Answer 2

首先，MVC 诞生于1979年，可以说，那个时期的电脑和现在的电脑完全不同。那个时候没有图形界面，电脑程序非常“僵硬”，需要操作员输入一个个指令（通常是键盘，也有读卡器），按照规定算法进行计算，并且返回结果。所以那个时期的 controller，负责接收用户指令、读写数据、调用 view 显示，即题主你的理解，其实是正确的。 现在几乎你能够在网上找到的所有对于 MVC、MVP 之间区别的讲解，几乎都是作者以“我的理解”，硬解释出来的，都是错的。其作者们无一例外全都忽视了计算机和图形界面的发展，带入当前的智能设备、虚拟组件（如按钮）来解释 MVC，认为 View 能够接受用户操作，将指令传给 controller，然后怎么怎么着。所以看起来都有各种逻辑不通的地方。 我所知道的正确讲解，只有这一篇：谈谈UI架构设计的演化。其实很简单，MVP 就是 MVC 的升级版，因为环境变了，输入设备变了，所以模式也变了。 令我失望的是，连 Addy Osami，在《JS设计模式》一书里，也说错了。 所以，楼主的理解基本正确。不过最好加上历史因素，这样更全面。 另外，现在经常看到的 Guard、service，则是根据业务需求，进一步抽象出来的角色和层，不影响 MVC/MVP 体系。

Answer 3

mvc，怎么说呢? 说起来还是比较抽象的。 一般为了层次结构更加清晰，会明确各层的作用。 controller主要请求转发，model层主要处理业务逻辑，有时候也是看业务的复杂程度，如果业务相当简单，model显然有点多余了，model也有人会去直接在view中进行use 直接进行渲染处理，本身mvc也是基于软件的变化，而总结出来的一种经验，其目的也是为了团队更好的协同开发，适应复杂的业务等。具体还是要看公司的业务的复杂程度，model层与view的直接交互个人是觉的这种做法欠妥当，第一不利于前后端分离，二来代码可读性降低，现在更好的做法都是后端提供api接口 前端处理接口。 所以。没有绝对的mvc 只有适合业务变化的mvc。

Answer 4

YII 就是用M去操作V，尤其是用它的小组件的时候，逻辑都在M里

Answer 5

没有对错，只要mvc相互分离就行了，是软件设计的艺术