浅谈 MVC、MVP 和 MVVM 架构模式 · /mvx

[draveness]

https://draveness.me/mvx

[YunyueLin]

作者你好~：
监督控制器的 MVP 模式，View 层和 Model 层是存在耦合的啊， 但是你又说了 "另一个 MVP 与 MVC 之间的重大区别就是，MVP（Passive View）中的视图和模型是完全解耦的，它们对于对方的存在完全不知情，这也是区分 MVP 和 MVC 的一个比较容易的方法。" 这是怎么回事呢

[draveness]

@YunyueLin
作者你好~：
监督控制器的 MVP 模式，View 层和 Model 层是存在耦合的啊， 但是你又说了 "另一个 MVP 与 MVC 之间的重大区别就是，MVP（Passive View）中的视图和模型是完全解耦的，它们对于对方的存在完全不知情，这也是区分 MVP 和 MVC 的一个比较容易的方法。" 这是怎么回事呢

MVP 的架构模式是有两种情况的，一种叫做 supervising controller 另一种是 passive view，后者由于 vm 之间没有任何的联系，所以能够与 MVC 之间比较容易的区分，这里可能没有说清楚

[YunyueLin]

@draveness

@YunyueLin
作者你好~：
监督控制器的 MVP 模式，View 层和 Model 层是存在耦合的啊， 但是你又说了 "另一个 MVP 与 MVC 之间的重大区别就是，MVP（Passive View）中的视图和模型是完全解耦的，它们对于对方的存在完全不知情，这也是区分 MVP 和 MVC 的一个比较容易的方法。" 这是怎么回事呢

MVP 的架构模式是有两种情况的，一种叫做 supervising controller 另一种是 passive view，后者由于 vm 之间没有任何的联系，所以能够与 MVC 之间比较容易的区分，这里可能没有说清楚

恩 。: )

[tisfeng]

好文，学习了

[sfshine]

深度好文

[expkzb]

图非常好看，请问是拿什么工具绘制的？

[RyanHu]

好文章。设计模式都在倡导解耦和隔离，但是各种MVC、MVP、MVVM在实际中并没有看到十分明确的标准。
我觉得倡导解耦是ok的，但是一个完整的业务怎么可能一点耦合都没有呢？

[zknyy]

既然笔者都把Smalltalk拿出来了，是不是也应该把Java Swing和更早期的AWT也分析一下。
另外，binder这个东西貌似不是M$最先有的（无论从概念还是产品，请调研一下曾经辉煌的Borland，Powersoft甚至更早期公司的产品或许能有更多的发现）

[draveness]

@zknyy
既然笔者都把Smalltalk拿出来了，是不是也应该把Java Swing和更早期的AWT也分析一下。
另外，binder这个东西貌似不是M$最先有的（无论从概念还是产品，请调研一下曾经辉煌的Borland，Powersoft甚至更早期公司的产品或许能有更多的发现）

对 Java 并不了解，另外我好像没有说过是 M$ 最先有的吧。。

[WeiJun0827]

好文!!

[aslecu]

你好，想问下你作图的软件是什么，非常漂亮简洁

[palexu]

赞

[qiushi0908]

这种抽象的模型还是需要示例代码辅助理解
show code!!

[lxqxsyu]

文章内的示意图是用什么工具绘制的？

[czy1996]

@aslecu
你好，想问下你作图的软件是什么，非常漂亮简洁

同问呢

[draveness]

这个过程用户操作面向的到底是哪个层？

视图层

控制器不能实现更新模型，通知视图更新，视图请求模型这个样一个顺序，因为控制器必须先和视图沟通，才知道更新哪个模型。这样的话，控制器和视图就应该是双向箭头吧。

因为控制器必须先和视图沟通 V 在事件发生时就通知 C 是啥事件，需要更新什么 Model 了，不需要反过来再查询

[SepCode]

@draveness

这个过程用户操作面向的到底是哪个层？

视图层

控制器不能实现更新模型，通知视图更新，视图请求模型这个样一个顺序，因为控制器必须先和视图沟通，才知道更新哪个模型。这样的话，控制器和视图就应该是双向箭头吧。

因为控制器必须先和视图沟通 V 在事件发生时就通知 C 是啥事件，需要更新什么 Model 了，不需要反过来再查询

• 嗯，我的第二个如果就是面向的是视图层，不应该站在苹果事件传递链的角度，应该站在响应链的角度。这样就是：V响应用户操作，交给C处理。C更新Model，拿到数据，再去更新V。
• 这样的话标准的MVC怎么实现呢：

控制器负责对模型中的数据进行更新，而视图向模型中请求数据；当有用户的行为触发操作时，会有控制器更新模型，并通知视图进行更新，在这时视图向模型请求新的数据，而这就是作者所理解的标准 MVC 模式下

这个用户面向的如果也是V的话，那视图响应用户操作，接下来的指向呢？是交给C处理，还是直接请求Model。

• 交给C处理又回到了目前的MVC
• 直接请求数据，那Model就和View耦合，就不需要C参与了。
  我想理解用户面向视图层，你所理解的标准MVC应该是怎么一个交互顺序。

[zhudengdengdeng]

防止 -> 放置

[AmyFoxFN]

"当多个视图共享相同的数据时，观察者同步是一个非常关键的模式，它能够在对这些视图不知情的前提下，同时通知多个视图；通过观察者模式，我们可以非常容易地创建一个依赖于同一模型的视图。"

这句话感觉理解起来不太符合上下文。是否是这个意思呢：

"...它能够在对 模型 不知情的前提下，同时通知多个视图；通过观察者模式，我们可以非常容易地创建 多 个依赖于同一模型的视图。"

[vipstone]

流程图画的不错，作者的画图工具用的啥呀？

[954788]

学到很多👍

[97Yates05]

写的很棒，受益匪浅，不过还有个疑问，现在的web的服务端只有m和c吧，因为现在的web后端基本只负责api接口，不负责渲染视图

[draveness]

写的很棒，受益匪浅，不过还有个疑问，现在的web的服务端只有m和c吧，因为现在的web后端基本只负责api接口，不负责渲染视图

JSON 也是 View 的一种

[97Yates05]

写的很棒，受益匪浅，不过还有个疑问，现在的web的服务端只有m和c吧，因为现在的web后端基本只负责api接口，不负责渲染视图

JSON 也是 View 的一种

可以。受教了

[listenzz]

@aslecu
你好，想问下你作图的软件是什么，非常漂亮简洁

应该是 keynote, 只是不知水印是怎么打上去的

[draveness]

@aslecu
你好，想问下你作图的软件是什么，非常漂亮简洁

应该是 keynote, 只是不知水印是怎么打上去的

https://draveness.me/sketch-and-sketch/

[kabda]

关于类MVC的架构，我之前也有过一段时间的研究，我感觉，根本性问题是在于对M的理解上，一直以来，我对M的理解为“业务模型”，而不是“数据模型”。如果把M理解为业务模型，视图负责展示，控制器负责调度，基本上不就会需要再衍生出其他类MVC架构了；但是如果把M理解为数据模型，就会像文章中提到的，控制器需要去承载大量的业务逻辑，而控制器与视图在某种程序上的绑定关系，也导致了业务不可迁移。

[caowent]

"虽然说整个架构图的逻辑是可以说的通的，不过相比于前面的架构图总是感觉有一些奇怪，而在这幅图片中，视图和控制器之间是毫无关系的，这与前面见到的所有 MVC 架构模式都完全不同，作者也不清楚这幅图来源是什么、为什么这么画，放在这里也仅作参考。"

关于维基百科上的MVC我在仪表开发中应用过这种模式。这种模式一般是实体按键（可看作控制器），没有视图控件的应用实列（控制器和视图物理上分离）。比如掌上游戏机，按下游戏手柄，游戏的内容发生变更，这其中实质是控制器更新了model，视图再从model获得数据，进一步渲染展示出来。

[caowent]

@RyanHu
好文章。设计模式都在倡导解耦和隔离，但是各种MVC、MVP、MVVM在实际中并没有看到十分明确的标准。
我觉得倡导解耦是ok的，但是一个完整的业务怎么可能一点耦合都没有呢？

耦合确实存在，解耦更具体地理解可以是降低耦合。耦合不能消除，但耦合有强弱好坏之分，数据耦合就优于内容耦合。我们可以通过设计模式降低耦合。

软件工程中的各种耦合类型
内容耦合(Content Coupling) ...
公共耦合(Common Coupling) ...
外部耦合(External Coupling) ...
控制耦合(Control Coupling) ...
印记耦合(Stamp Coupling) ...
数据耦合(Data Coupling) ...
非直接耦合(Nondirect Coupling)

https://blog.csdn.net/qq_20480611/article/details/51329688

[imageslr]

记得之前阅读分布式文章的时候，有许多“相关文章”，我就总是递归地阅读每一篇。最近想回顾一下，发现这些文章都不见了，变成了标签 {% include related/...md %}。可以修复嘛？