当超越RAD（拖放和配置）构建用户界面的方式时，许多工具都鼓励您使用三种设计模式，即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分：
这些模式解决了什么问题？它们有什么相似之处？它们有何不同？
这两个框架都旨在分离关注点-例如，与数据源（模型）的交互、应用程序逻辑（或将这些数据转换为有用信息）（控制器/演示者）和显示代码（视图）。在某些情况下，模型还可以用于将数据源转换为更高级别的抽象。MVC Storefront项目就是一个很好的例子。
这里讨论了MVC与MVP之间的区别。
所做的区别在于，在MVC应用程序中，视图和控制器传统上与模型交互，而不是彼此交互。
MVP设计让演示者访问模型并与视图交互。
尽管如此，根据这些定义，ASP.NET MVC是MVP框架，因为控制器访问模型以填充视图，这意味着没有逻辑（只显示控制器提供的变量）。
要了解ASP.NET MVC与MVP的区别，请查看Scott Hanselman的MIX演示。
不久前，我在博客中引用了托德·斯奈德（Todd Snyder）关于两者区别的精彩文章：
以下是模式：MVP模式视图与模型的耦合更加松散。演示者是负责将模型绑定到视图。更容易进行单元测试，因为与视图的交互是通过的接口通常视图到演示者的映射是一对一。复杂视图可能具有多主持人。MVC模式控制器基于行为，可以在意见可以负责确定要显示的视图
这是我能在网上找到的最好的解释。
MVP=模型视图演示者MVC=模型视图控制器两种演示模式。它们将模型（考虑域对象）、屏幕/网页（视图）和用户界面（演示者/控制器）之间的依赖关系分开它们在概念上相当相似，人们根据口味对演示者/控制器进行不同的初始化。这里有一篇关于差异的精彩文章。最值得注意的是MVC模式具有更新视图的模型。
MVP：观点是主导的。
在大多数情况下，视图会创建其演示者。演示者将与模型交互并通过界面操纵视图。视图有时会与演示者交互，通常是通过某种界面。这归结于实施；您希望视图调用演示者上的方法，还是希望视图具有演示者侦听的事件？归结起来就是：视图了解演示者。视图将委派给演示者。
MVC：控制器负责。
控制器是根据某些事件/请求创建或访问的。然后，控制器创建适当的视图并与模型交互以进一步配置视图。它归结为：控制器创建和管理视图；视图从属于控制器。视图不知道控制器。
同样值得记住的是，MVP也有不同的类型。福勒将这种模式分为两种：被动视图和监督控制器。
使用被动视图时，视图通常实现一个细粒度的接口，其中财产或多或少直接映射到底层UI小部件。例如，您可能有一个具有诸如Name和Address等财产的ICustomerView。
您的实现可能如下所示：
public class CustomerView : ICustomerView
{
public string Name
{
get { return txtName.Text; }
set { txtName.Text = value; }
}
}
Presenter类将与模型对话，并将其“映射”到视图。这种方法被称为“被动视图”。好处是视图易于测试，并且更容易在UI平台（Web、Windows/XML等）之间移动。缺点是无法利用数据绑定（在WPF和Silverlight等框架中，数据绑定功能非常强大）。
MVP的第二个特点是监督控制员。在这种情况下，您的View可能有一个名为Customer的属性，然后该属性再次绑定到UI小部件。您不必考虑同步和微观管理视图，监督控制器可以在需要时介入并提供帮助，例如使用复杂的交互逻辑。
MVP的第三个“味道”（或者有人可能会称之为一个单独的模式）是演示模型（或者有时称为模型-视图-视图模型）。与MVP相比，你将M和P“合并”为一个类。您有UI小部件数据绑定到的客户对象，但也有其他UI特定字段，如“IsButtonEnabled”或“IsReadOnly”等。
我认为我找到的最好的UI架构资源是Jeremy Miller在the Build Your Own CAB系列目录上发表的一系列博客文章。他涵盖了MVP的所有风格，并展示了实现它们的C#代码。
我也在YouCard网站上写过关于Silverlight上下文中的模型-视图-视图-模型模式的博客。
MVP不一定是视图负责的场景（例如，参见Taligent的MVP）。我觉得很不幸的是，人们仍在宣扬这是一种模式（主管视图），而不是一种反模式，因为它与“这只是一种观点”（实用主义程序员）相矛盾。“这只是一个视图”表示，向用户显示的最终视图是应用程序的次要关注点。微软的MVP模式使视图的重用变得更加困难，并方便地为微软的设计师提供了避免不良做法的借口。
坦率地说，我认为MVC的底层关注点对于任何MVP实现都是正确的，它们之间的差异几乎完全是语义上的。只要您遵循视图（显示数据）、控制器（初始化和控制用户交互）和模型（底层数据和/或服务）之间的关注点分离，就可以实现MVC的好处。如果您正在实现这些好处，那么谁会真正关心您的模式是MVC、MVP还是Supervisory Controller？唯一真正的模式仍然是MVC，其余的只是不同的风格。
考虑一下这篇激动人心的文章，它全面列出了许多不同的实现。你可能会注意到，他们基本上都在做相同的事情，但略有不同。
我个人认为MVP是最近才被重新引入的一个吸引人的术语，目的是为了减少语义偏执者之间的争论，他们争论某些东西是否真正是MVC，或者是为了证明微软的快速应用程序开发工具的合理性。在我的书中，这两个原因都不能证明它是一种独立的设计模式。
表示器
在MVP中，演示者包含视图的UI业务逻辑。视图中的所有调用都直接委派给演示者。演示者也直接与视图分离，并通过接口与视图对话。这是为了允许在单元测试中模拟视图。MVP的一个共同特点是必须有很多双向调度。例如，当有人单击“保存”按钮时，事件处理程序将委托给演示者的“OnSave”方法。保存完成后，演示者将通过其界面调用视图，以便视图显示保存已完成。
MVP往往是在WebForms中实现分离表示的一种非常自然的模式。原因是视图总是首先由ASP.NET运行时创建。您可以了解更多关于这两种变体的信息。
两种主要变化
被动视图：视图尽可能地哑，几乎包含零逻辑。演示者是与视图和模型对话的中间人。视图和模型彼此完全屏蔽。模型可能会引发事件，但演示者会订阅这些事件以更新视图。在被动视图中，没有直接的数据绑定，相反，视图公开了演示者用于设置数据的setter财产。所有状态都在演示者中管理，而不是在视图中管理。
Pro：最大可测试表面；视图和模型的清晰分离缺点：更多的工作（例如所有setter财产），因为您正在自己进行所有数据绑定。
监督控制器：演示者处理用户手势。视图通过数据绑定直接绑定到模型。在这种情况下，演示者的工作是将模型传递给视图，以便它可以绑定到它。演示者还将包含诸如按下按钮、导航等手势的逻辑。
优点：通过利用数据绑定，减少了代码量。缺点：有一个不太可测试的表面（因为数据绑定），并且视图中的封装更少，因为它直接与模型对话。
模型视图控制器
在MVC中，控制器负责确定响应于任何操作（包括应用程序加载时）显示哪个视图。这与MVP不同，MVP将动作通过视图传递到演示者。在MVC中，视图中的每个动作都与对Controller的调用以及动作相关。在网络中，每个动作都涉及到对URL的调用，URL的另一端有一个控制器进行响应。控制器完成处理后，将返回正确的视图。该序列在应用程序的整个生命周期中以这种方式继续：
Action in the View
-> Call to Controller
-> Controller Logic
-> Controller returns the View.
MVC的另一个重要区别是视图不直接绑定到模型。该视图只是呈现，完全无状态。在MVC的实现中，视图通常在代码后面没有任何逻辑。这与MVP相反，MVP是绝对必要的，因为如果视图不委托给演示者，它将永远不会被调用。
演示模型
另一种模式是演示模型模式。在此模式中，没有演示者。相反，视图直接绑定到演示模型。演示模型是专门为视图设计的模型。这意味着该模型可以公开人们永远不会放在域模型上的财产，因为这将违反关注分离。在这种情况下，表示模型绑定到域模型，并可以订阅来自该模型的事件。然后，视图订阅来自演示模型的事件，并相应地更新自己。表示模型可以公开视图用于调用操作的命令。这种方法的优点是，当PM完全封装了视图的所有行为时，您基本上可以完全删除代码。这种模式非常适合在WPF应用程序中使用，也称为模型视图视图模型。
MSDN上有一篇关于演示模型的文章，WPF（前Prism）的复合应用指南中有一节关于分离的演示模式
这两种模式都试图分离表示和业务逻辑，将业务逻辑与UI方面分离
在架构上，MVP是基于页面控制器的方法，而MVC是基于前端控制器的方法。这意味着MVP标准的web表单页面生命周期只是通过从代码后面提取业务逻辑来增强的。换句话说，page是为http请求提供服务的页面。换句话说，MVP IMHO是一种网络形式的进化型增强。另一方面，MVC完全改变了游戏，因为在加载页面之前，请求被控制器类拦截，在那里执行业务逻辑，然后在控制器处理刚刚转储到页面的数据的最终结果（“视图”）从这个意义上讲，MVC看起来（至少在我看来）很像MVP的Supervisory Controller风格，它通过路由引擎增强了MVP的功能
这两种方法都支持TDD，并有其优缺点。
关于如何选择其中一个IMHO的决定应该基于在ASP.NET web表单类型的web开发中投入的时间。如果有人认为自己擅长网络形式，我会建议MVP。如果你在页面生命周期等方面感觉不太舒服的话，MVC可能是一种方法。
下面是另一个博客文章链接，提供了关于这个主题的更多细节
http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx
我已经使用了MVP和MVC，尽管我们作为开发人员倾向于关注这两种模式的技术差异，但IMHO中MVP的要点与易于采用性比其他任何东西都更相关。
如果我所在的团队已经具备良好的web表单开发风格背景，那么引入MVP比引入MVC要容易得多。我认为MVP在这种情况下是一场快速的胜利。
我的经验告诉我，将团队从web表单转移到MVP，然后从MVP转移到MVC相对容易；从web表单迁移到MVC更加困难。
我在这里留下一个链接，指向我的一个朋友发表的关于MVP和MVC的一系列文章。
http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx
我简短的观点是：MVP适用于大范围，MVC适用于小范围。有了MVC，我有时会觉得V和C可能被看作是一个不可分割的组件的两面，而不是直接绑定到M，当向下扩展到较短的规模时，如UI控件和基本控件时，必然会出现这种情况。在这种粒度级别上，MVP意义不大。相反，当一个人走向更大的规模时，适当的界面变得更重要，同样，明确的职责分配也同样重要，MVP就来了。
另一方面，当平台特性有助于组件之间的某种关系时，例如在web上，MVC的实现似乎比MVP更容易。
在MVP中，视图从演示者中提取数据，演示者从模型中提取数据并准备/规范化数据，而在MVC中，控制器通过在视图中推送从模型中获取数据并进行设置。
在MVP中，您可以使用一个视图来处理多种类型的演示者，也可以使用单个演示者来处理不同的多个视图。
MVP通常使用某种绑定框架，例如Microsoft WPF绑定框架或HTML5和Java的各种绑定框架。
在这些框架中，UI/HTML5/XAML知道每个UI元素显示的演示者的属性，因此当您将视图绑定到演示者时，视图会查找财产，并知道如何从中绘制数据，以及当用户在UI中更改值时如何设置这些属性。
因此，例如，如果模型是一辆汽车，那么演示者是某种汽车演示者，向视图公开汽车的财产（年份、制造商、座位等）。视图知道名为“car maker”的文本字段需要显示演示者maker属性。
然后，您可以将许多不同类型的演示者绑定到视图中，所有演示者都必须具有Maker属性-它可以是飞机、火车或其他任何类型的视图，视图都不在乎。视图从演示者（无论是哪一个）获取数据，只要它实现了一个商定的接口。
这个绑定框架，如果你去掉它，它实际上就是控制器：-）
因此，您可以将MVP视为MVC的演变。
MVC很好，但问题是它的控制器通常是每个视图。控制器A知道如何设置视图A的字段。如果现在，您希望视图A显示模型B的数据，您需要控制器A了解模型B，或者需要控制器A接收带有接口的对象，这就像MVP一样，只是没有绑定，或者您需要重写控制器B中的UI设置代码。
结论：MVP和MVC都是UI模式的解耦，但MVP通常使用一个绑定框架，该框架的底层是MVC。THUS MVP的体系结构级别高于MVC，并且是MVC之上的包装模式。
MVC（模型视图控制器）
输入首先指向控制器，而不是视图。该输入可能来自与页面交互的用户，但也可能来自简单地在浏览器中输入特定的url。在任何一种情况下，它都是一个控制器，与之接口以启动某些功能。控制器和视图之间存在多对一关系。这是因为单个控制器可以基于正在执行的操作选择要渲染的不同视图。注意从控制器到视图的单向箭头。这是因为视图对控制器没有任何了解或参考。控制器确实会传递回模型，因此视图和传递给它的预期模型之间存在知识，而不是提供服务的控制器。
MVP（模型视图演示者）
输入以视图开始，而不是演示者。视图和关联的演示者之间有一对一的映射。视图包含对演示者的引用。演示者也会对从视图触发的事件做出反应，从而了解与其关联的视图。演示者根据对模型执行的请求操作更新视图，但视图不支持模型。
更多参考信息
MVP
MVP代表模型-视图-演示者。2007年初，微软推出了Smart Client windows应用程序。
演示者在MVP中充当监督角色，MVP绑定模型中的视图事件和业务逻辑。
视图事件绑定将从视图界面在Presenter中实现。
视图是用户输入的发起者，然后将事件委派给演示者，演示者处理事件绑定并从模型中获取数据。
赞成的意见：视图只有UI，没有任何逻辑高水平的可测试性
欺骗：实现事件绑定时有点复杂，工作量更大
MVC
MVC代表模型视图控制器。控制器负责创建模型并使用绑定模型渲染视图。
控制器是启动器，它决定渲染哪个视图。
赞成的意见：强调单一责任原则高水平的可测试性
欺骗：如果试图在同一控制器中渲染多个视图，有时控制器的工作量太大。
最简单的答案是视图如何与模型交互。在MVP中，视图由演示者更新，演示者充当视图和模型之间的中介。演示者从视图中获取输入，视图从模型中检索数据，然后执行所需的任何业务逻辑，然后更新视图。在MVC中，模型直接更新视图，而不是通过控制器返回。
模型视图控制器
MVC是软件应用程序架构的一种模式。它将应用程序逻辑分为三个独立的部分，促进了模块化和易于协作和重用。它还使应用程序更灵活，更易于迭代。它将应用程序分为以下组件：
处理数据和业务逻辑的模型用于处理用户界面和应用程序的控制器用于处理图形用户界面对象和演示的视图
为了更清楚一点，让我们想象一个简单的购物清单应用程序。我们只需要一份本周需要购买的每件商品的名称、数量和价格的清单。下面我们将描述如何使用MVC实现这些功能。
表示器
模型是将在视图（用户界面）中显示的数据。该视图是一个界面，它显示数据（模型）并将用户命令（事件）发送给演示者，以根据该数据进行操作。视图通常引用其演示者。演示者是“中间人”（由MVC中的控制器扮演），并同时引用视图和模型。请注意，“模型”一词具有误导性。它应该是检索或操纵模型的业务逻辑。例如：如果您有一个数据库将User存储在数据库表中，并且您的View希望显示用户列表，那么Presenter将具有对数据库业务逻辑（如DAO）的引用，Presenter将从中查询用户列表。
如果您想查看具有简单实现的示例，请检查此GitHub帖子
从数据库中查询和显示用户列表的具体工作流可以如下所示：
MVC模式和MVP模式有什么区别？
MVC模式
控制器基于行为，可以跨视图共享可以负责确定要显示的视图（前控制器模式）
MVP模式
视图与模型的耦合更加松散。演示者负责将模型绑定到视图。更容易进行单元测试，因为与视图的交互是通过接口进行的通常视图到演示者的映射是一对一。复杂视图可能有多个演示者。
鲍勃叔叔的这段视频很好，他在最后简要解释了MVC和MVP。
IMO，MVP是MVC的一个改进版本，基本上可以将你要显示的内容（数据）与你要显示（视图）的方式分开。演示者包含了UI的某种业务逻辑，隐式地规定了应该显示哪些数据，并为您提供了一个哑视图模型列表。当显示数据时，只需将视图（可能包含相同的id）插入适配器，并使用这些视图模型设置相关的视图字段，只需引入最少的代码（仅使用setter）。它的主要好处是您可以针对许多/各种视图测试UI业务逻辑，例如在水平列表或垂直列表中显示项目。
在MVC中，我们通过接口（边界）来粘合不同的层。控制器是我们体系结构的一个插件，但它对显示内容没有任何限制。从这个意义上讲，MVP是一种MVC，其概念是视图可以通过适配器插入控制器。
我希望这有助于更好。
这个问题有很多答案，但我觉得需要一些非常简单的答案来清楚地比较两者。以下是我在用户在MVP和MVC应用程序中搜索电影名称时所做的讨论：
用户：单击…
观点：那是谁？[MVP|MVC]
用户：我刚刚点击了搜索按钮…
视图：好的，等一下。[MVP|MVC]
（视图调用演示者|控制器…）[MMVP|MVC]
视图：嗨，演示者|控制器，用户刚刚单击了搜索按钮，我该怎么办？[MVP|MVC]
演示者|控制器：嘿，View，那个页面上有搜索词吗？[MVP|MVC]
视图：是的，…这里是…“钢琴”[MMVP|MVC]
演示者|控制器：谢谢查看，……同时我正在查找模型上的搜索项，请向他/她显示进度条[MVP|MVC]
（演示者|控制器正在调用模型…）[MMVP|MVC]
演示者|控制器：嘿，模特儿，你有匹配这个搜索词的吗？：“钢琴”[MVP|MVC]
模型：嘿，演示者|控制器，让我检查一下…〔MVP|MVC〕
（模型正在对电影数据库进行查询…）[MVP|MVC]
（过了一会儿…）
--------------这就是MVP和MVC开始分化的地方---------------
模型：我为您找到了一个列表，演示者，这里是JSON格式的“[{“name”：“Piano Teacher”，“year”：2001}，{“name:”Piano”，“year”：1993}]”[MVP]
模型：有一些结果可用，控制器。我在实例中创建了一个字段变量，并用结果填充它。它的名称是“searchResultsList”[MVC]
（演示者|控制器感谢模型并返回视图）[MMVP|MVC]
演示者：感谢等待View，我为您找到了一个匹配结果列表，并以可呈现的格式排列：[“Piano Teacher 2001”，“Piano 1993”]。请在垂直列表中向用户显示。也请现在隐藏进度条[MMVP]
控制器：感谢等待View，我已经向Model询问了您的搜索查询。它说它找到了一个匹配结果的列表，并将它们存储在其实例中名为“searchResultsList”的变量中。你可以从那里得到它。也请立即隐藏进度条[MVC]
观点：非常感谢演示者MVP
视图：谢谢“控制器”[MVC]（现在，视图正在质疑自己：我应该如何向用户展示我从模型中获得的结果？电影的制作年份应该是第一年还是最后一年……？它应该在垂直列表还是水平列表中？…）
如果你感兴趣的话，我一直在写一系列关于应用程序架构模式（MVC、MVP、MVVP、干净架构……）的文章，并在这里附上Github repo。尽管该示例是为android编写的，但其基本原理可以应用于任何介质。
我认为Erwin Vanderwalk的这张图片（以及附带的文章）是对MVC、MVP和MVVM及其相似性和差异的最好解释。这篇文章没有出现在搜索引擎的“MVC、MVP和MVVM”查询结果中，因为文章的标题没有包含“MVC”和“MVP”字样；但我认为这是最好的解释。
（这篇文章也符合鲍勃·马丁大叔在他的一次演讲中所说的：MVC最初是为小型UI组件而设计的，而不是为系统的架构而设计的）
简而言之，
在MVC中，View有UI部分，它调用控制器，控制器反过来调用模型&模型，然后将事件返回视图。在MVP中，视图包含UI，并调用演示者作为实现部分。演示者直接调用视图以更新UI部分。包含业务逻辑的模型由演示者调用，与视图没有任何交互。因此，演示者完成了大部分工作：）
你忘了动作域响应程序（ADR）。
正如上面的一些图形所解释的，MVC中的模型和视图之间有直接的关系/链接。在控制器上执行操作，控制器将在模型上执行操作。模型中的该操作将触发视图中的反应。视图在模型状态更改时始终更新。
有些人一直忘记了，MVC是在70年代末创建的，而Web只是在80年代末/90年代初创建的。MVC最初不是为Web创建的，而是为桌面应用程序创建的，其中Controller、Model和View将共存。
因为我们使用的是仍然使用相同命名约定（模型-视图-控制器）的web框架（例如：.Laravel），所以我们倾向于认为它必须是MVC，但实际上是其他东西。
相反，请查看操作域响应程序。在ADR中，控制器获得一个动作，该动作将在模型/域中执行操作。到目前为止，情况是一样的。不同的是，它然后收集该操作的响应/数据，并将其传递给Responder（例如：.view（））进行渲染。当在同一组件上请求新操作时，将再次调用Controller，并重复循环。在ADR中，模型/域和视图（Reposer的响应）之间没有任何联系。
注意：维基百科指出“然而，每个ADR动作都由单独的类或闭包表示”。这不一定是真的。多个操作可以在同一控制器中，并且模式仍然相同。
mvc adr模型视图控制器动作域响应器
MVC（模型视图控制器）
在MVC中，控制器是负责人！控制器根据一些事件/请求触发或访问，然后管理视图。
MVC中的视图实际上是无状态的，控制器负责选择要显示的视图。
例如：当用户单击“Show MyProfile”（显示我的配置文件）按钮时，将触发控制器。它与模型通信以获得适当的数据。然后，它会显示一个类似于配置文件页面的新视图。控制器可以从模型中获取数据并将其直接馈送到视图（如上图所示），或者让视图从模型本身获取数据。
MVP（模型视图演示者）
在MVP中，视图是负责人！每个视图都会调用其演示者或演示者收听的某些事件。
MVP中的视图不实现任何逻辑，演示者负责实现所有逻辑，并使用某种接口与视图进行通信。
例如：当用户单击“保存”按钮时，视图中的事件处理程序将委派给演示者的“OnSave”方法。演示者将执行所需的逻辑，并与模型进行任何所需的通信，然后通过其界面调用视图，以便视图显示保存已完成。
MVC与MVP
MVC并没有让视图负责，视图充当控制器可以管理和指导的从属对象。在MVC中，视图是无状态的，而MVP中的视图是有状态的，可以随时间变化。在MVP中，视图没有逻辑，我们应该尽可能让它们保持沉默。另一方面，MVC中的视图可能有某种逻辑。在MVP中，演示者与视图分离，并通过接口与视图对话。这允许在单元测试中模拟视图。在MVP中，视图与模型完全隔离。然而，在MVC中，视图可以与模型通信，以使其与最新的最新数据。
