小伙伴们更喜欢哪一个呢？我一直在研究两者，人们对它们的称呼似乎确实存在一些不一致之处。
我会尝试记下差异，如果我错了，你可以纠正我。
MVC
- 模型保存对其自己的观察者（视图）的引用，在模型更新时它会通知观察者。
- 视图将所有事件和消息传递给控制器。当模型通知视图发生更改时，视图会更新其内容。视图保存对控制器和模型的引用。
- 控制器保存模型和（有时）视图。视图将调用与用户输入相对应的控制器方法，然后控制器相应地操作模型，有时还会操作视图（阻止某些视图单击上的按钮等）
MVP
- 模型没有对视图的引用。只为程序提供数据抽象。模型没有任何参考。
- 与在 MVC 中一样，视图根据用户输入调用相应的 Presenter 方法。 View 仅引用 Presenter。
- Presenter 有对视图和模型的引用。当 View 调用 Presenter 中的方法时，Presenter 会操作 Model，然后操作 View。
我很确定我了解 MVC 的工作原理，只是我的理解 MVP 是否有点不确定。我真的很喜欢 MVC，但唯一不适合我的是模型，它应该只是数据层的抽象，也保存对视图的引用并进行更新。这没有道理。
马丁·福勒提供了一个analysis http://www.martinfowler.com/eaaDev/uiArchs.htmlMVC 和 MVP 以及 WikipediaMVP http://en.wikipedia.org/wiki/Model-view-presenter#cite_note-3文章给出了更多参考。
对我来说，有两个问题：
1）。模型-视图关系的“活跃度”如何？如果模型动态变化，并且视图必须更新以反映模型变化，那么我们就有经典的 MVC，并且模型以某种方式通知相关视图的变化。此样式不适用于经典 Web 应用程序（例如在 Struts 中实现的）。这里通常会创建一个作为模型快照的一个视图（实际上通常是在模型提供的 DTO 上）。在许多文献中，Web 风格仍然称为 MVC。
2）。当用户做“某事”时，谁负责解释和行动。在 MVC 中，这通常是控制器的工作。为此，MVP 似乎允许从视图到模型进行更直接的交互（如果我正确理解 Fowlers 文章的话）。
我更喜欢干净的关注点分离 - MVC 方法是我的想法，但这可能只是一个熟悉的事情。
一个人应该选择什么？一般来说，我认为您是由您选择使用的框架驱动的。我有 Struts 背景，所以 Web 风格的 MVC 对我来说很自然。如果我理解正确的话，MVP 在 .NET 的某些方面得到了明确的采用。我会遵循您选择的任何框架的流程，并且我不会仅仅因为它是 MVP 而不是 MVC 就拒绝一个框架 - 即使假设可以进行明确的区分。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
