MVC还是MVP？哪种设计模式最有意义？

Question

你们更喜欢哪个？我一直在研究两者，人们称之为肯定存在一些不一致的地方。

我会尝试记下差异，如果我错了你可以纠正我。

MVC

1. 模型保存对它自己的观察者（视图）的引用，对模型的更新通知观察者。
2. 视图将所有事件和消息传递给Controller。当模型通知发生了更改时，视图会更新其内容。 View包含对Controller和Model的引用。
3. Controller拥有Model和（有时）视图。视图将调用与用户输入相对应的控制器方法，然后控制器相应地对模型进行操作，有时操纵视图（在某些视图点击时阻止按钮等）。

MVP

1. 模型没有对视图的引用。仅提供程序的数据抽象。模型没有任何参考。
2. 与MVC视图一样，根据用户输入调用相应的Presenter方法。 View仅提供给Presenter。
3. Presenter引用了Views和Model。当View在Presenter中调用方法时，Presenter会操作模型然后操纵视图。

我很确定我理解MVC是如何工作的，只是我理解MVP是否有点不确定。我真的很喜欢MVC，但唯一不适合我的部分是，模型，它应该只是数据层的抽象，同时保存对视图的引用并进行更新。这没有意义。

Answer 1

Martin Fowler提供了analysis MVC和MVP，维基百科MVP文章提供了更多参考。

对我来说，有两个问题：

1）。模型 - 视图关系的“实时”如何？如果模型动态更改，并且视图必须更新以反映模型更改，那么我们将拥有经典的MVC，并且模型会以某种方式通知相关的更改视图。此样式不适用于经典Web应用程序（例如，在Struts中实现）。这里通常会创建一个View作为模型快照的一个视图（实际上通常在模型提供的DTO上）。在许多文献中，Web风格仍然被称为MVC。

2）。当用户做“某事”时，谁负责解释和行动。在MVC中，这通常是控制器作业。为此目的，MVP似乎允许从View到Model进行更直接的交互（如果我理解Fowlers文章的话）。

我更喜欢清晰分离问题 - MVC方法就是我的想法，但这可能只是一种熟悉的事情。

一个人应该选择什么？一般来说，我认为你是由你选择使用的框架驱动的。我来自Struts背景，所以网络风格的MVC对我来说很自然。如果我理解正确，MVP在.NET的某些方面有明确的采用。我会选择你选择的任何框架的流程，我不会因为它是MVP而不是MVC而拒绝框架 - 即使假设可以做出明确的区分。

Answer 2

MVVM怎么样？ （模型视图视图 - 模型）在此样式中，模型不包含对视图的任何引用，反之亦然。我不会假装知道太多，因为我只是刚刚开始学习它，但我们最近选择了转向这个设计模式，所以我假设它确实有一些优点。

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

Answer 3

在任何一种模式中，模型都不能依赖任何其他组件。 '仅引用'对Observer对象。它们并不关心这些观察者是观点，控制者还是其他模型。

MVC是最错误引用的设计模式，缺乏真正的定义。我将使用Martin Fowler发表的那篇。

让我们考虑一个UI / CRUD屏幕/用于桌面应用程序中的复杂业务对象。 （像MVC这样的Struts有点不同）。 您有一个Model（业务对象），屏幕上有多个视图，每个视图都有自己的控制器。

UI逻辑（验证，启用与业务对象相关的小部件）分散在整个View和Controller对象中。从这个意义上讲，MVC模式已经过时（！），但当时关注点的分离是革命性的，并且可以实现更丰富的用户界面。

在MVP中你有模型，一个视图，这是愚蠢的，所有UI逻辑都在Presenter中。 Presenters为View元素提供Actions / Event处理程序/ Delegates。因此，当用户与屏幕上的相应小部件交互时，View仅回调Presenter。 Presenter充当介体，封装了小部件的交互方式。

我真的推荐这个链接http://martinfowler.com/eaaDev/uiArchs.html。整个MVC主题并不像听起来那么容易。它本身几乎就是一种理论。

Answer 4

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

我会这样说，你对MVC / MVP应该如何实现的定义可能与下一个人略有不同。我认为这种模式存在于关注点分离的一般概念中，但它可以进行调整以完全符合您对特定实现所需的内容。

Answer 5

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