MVC还是MVP？哪种设计模式更合理？

Question

你们更喜欢哪种？我一直在研究两者之间的区别，人们对它们的称呼似乎存在一些不一致。

我将尝试记录它们之间的差异，如果有错误，请纠正我。

MVC

1. Model 持有其自身观察者（Views）的引用，在更新模型时通知观察者。 2. Views 将所有事件和消息传递给 Controller。当模型通知视图发生更改时，视图会更新其内容。View 持有对 Controller 和 Model 的引用。 3. Controller 持有 Model 和（有时也持有）Views。Views 会调用与用户输入相应的 Controllers 方法，然后 Controller 根据需要操作 Model，并有时操作 View（阻止某些 View 点击上的按钮等）。

MVP

1. Model 没有引用 View。只为程序提供数据抽象。Model 不持有任何引用。 2. 与 MVC 中一样，View 根据用户输入调用相应的 Presenter 方法。View 仅引用 Presenter。 3. Presenter 持有 Views 和 Model 的引用。当 View 调用 Presenter 中的方法时，Presenter 操作 Model，然后操作 View。

我很确定我理解了 MVC 是如何工作的，但我对 MVP 的理解有点模糊。我非常喜欢 MVC，但唯一让我不太满意的部分是 Model，它应该只是数据层的抽象，但也持有对 Views 的引用并进行更新。这没有意义。

- DevDevDev

---

在使用长行文字时，我认为引用块比代码示例块更易读。 - Emile Vrijdags

https://dev59.com/h3VD5IYBdhLWcg3wXacd - Mike Woodhouse

@ejac，我该如何进行代码块引用？ - DevDevDev

我的理解是正确的吗，伙计们？ - DevDevDev

你可能会发现https://dev59.com/BnRB5IYBdhLWcg3wV196的答案很有帮助，因为它们谈到了在使用windows-forms实现MVC和MVP时的不同选项。 - Ian Ringrose

Answer 1

马丁·福勒（Martin Fowler）对MVC和MVP进行了解析，维基百科的MVP文章提供了更多参考资料。

对我来说，有两个问题：

1). 模型-视图关系有多“活跃”？如果模型动态更改，而视图必须更新以反映该模型更改，则我们具有经典MVC，并且模型会以某种方式通知相关视图进行更改。这种风格不适用于经典Web应用程序（例如在Struts中实现）。在这里，通常会创建一个视图作为模型快照的一次性生成（事实上，通常是由模型提供的DTO）。在许多文献中，Web样式仍被称为MVC。

2). 当用户执行“某些操作”时，谁负责解释和采取行动。在MVC中，通常是控制器的工作。如果我正确理解福勒的文章，MVP似乎允许从视图到模型的更直接交互来实现此目的。

我更喜欢清晰的关注点分离- MVC方法是我思考的方式，但这可能只是熟悉的事情。

一个人应该选择什么？通常来说，我认为你会受到你选择使用的框架所驱动。我来自Struts背景，因此Web风格的MVC对我来说很自然。如果我理解正确，MVP在.NET的某些方面已经明确采用了。我会跟随你选择的任何框架的潮流，并且不会仅仅因为它是MVP而不是MVC就拒绝一个框架 - 即使假设可以清楚地区分两者。

- djna

Answer 2

MVVM是什么？（Model View View-Model）在这种风格中，模型不持有对视图的引用，反之亦然。我不会假装自己很懂，因为我只是刚开始学习它，但我们最近选择转向这种设计模式，所以我认为它确实有一些优点。

http://en.wikipedia.org/wiki/Model_View_ViewModel

- thepaulpage

---

你是先决定使用MVVM，然后去寻找（或开发）实现方式，还是采用某个产品（或框架），并发现它的结构被描述为MVVM呢？我猜应该是后者 :-) 而且我认为这通常是现在的做法。我们在使用的东西中检测到MVC等模式，我们不需要经常自己做出实现选择。 - djna

Answer 3

在任何一种模式中，模型都不能依赖于其他组件。只有对观察者对象有引用。它不关心这些观察者是视图、控制器还是其他模型。

MVC 是最常被误解的设计模式，缺乏真正的定义。我将使用 Martin Fowler 发布的定义。

让我们考虑一个桌面应用程序中复杂业务对象的 UI/CRUD 屏幕。 (类似 Struts 的 MVC 有点不同)。您有一个模型 (业务对象)，屏幕上有几个视图，每个视图都有自己的控制器。

UI 逻辑 (验证、启用与业务对象相关的小部件) 分散在视图和控制器对象中。从这个意义上说，MVC 模式已经过时了(!)，尽管当时关注点分离是革命性的，并且使 UI 更加丰富。

在 MVP 中，您有模型、一个呆板的视图，所有的 UI 逻辑都在 Presenter 中。Presenter 为视图元素提供操作/事件处理程序/委托。因此，当用户与屏幕上相应的小部件交互时，视图仅回调到 Presenter。Presenter 充当中介，封装小部件的交互方式。

我非常推荐这个链接 http://martinfowler.com/eaaDev/uiArchs.html。整个MVC主题不像听起来那么简单，它几乎是一个独立的理论。

- Karl

Answer 4

假设我的理解是正确的，在MVP或MVC中，模型不应该持有对视图的引用。

不过我要说的是，你对于MVC/MVP的实现方式的定义可能与其他人略有不同。我认为这个模式存在的目的是为了实现关注点分离的一般思想，但它可以根据特定的实现需求进行调整。

- Max Schmeling

---

我认为您的理解是不正确的。我查看过的任何设计模式书籍都以相同的方式编写MVC，其中Model具有一个IObserver的ArrayList，而View实现了IObserver。 - DevDevDev

@SteveM，Max所说的是正确的，模型不持有对View的引用，而是持有对一些IObservers的引用（IObserver != IVew）。只要模型没有直接使用视图的方法，它是否实际持有对视图的引用就无关紧要，因为它只将其视为一个IObserver...从模型的角度来看，它没有意识到任何视图的存在。 - Pop Catalin

抱歉，我意识到我应该说的是IObserver而不是View，但我只想使用M、V或C以使其简单。 - DevDevDev

Answer 5

我认为这取决于你所处的环境。在Web环境中，控制器选择要显示哪个视图，作为请求的结果。在此之前，控制器会检查模型是否有任何更改。换句话说，视图不需要与模型直接连接。

- dutch