Presenter、Presentation Model、ViewModel 和 Controller 有什么区别？
我很清楚这些模式是如何工作的，也知道它们之间的一些细微差别，但它们真的有那么不同吗？
在我看来，Presenter、Presentation Model、ViewModel 和 Controller 本质上是同一个概念。
为什么我不能将所有这些概念归类为控制器？我觉得它可以大大简化整个想法。
谁能清楚地描述他们的差异？
我想澄清的是，我确实了解这些模式是如何工作的，并且已经用一种或另一种技术实现了其中的大部分。我真正想要的是某人对这些模式之一的体验，以及为什么他们不认为他们的 ViewModel 是一个控制器。
我会为此提供一些声誉点，但我正在寻找一个非常好的答案。
I have a pretty good idea how each of these patterns work and know about some of the minor differences between them, but are they really all that different from each other?
It seems to me that the Presenter, Presentation Model, ViewModel and Controller are essentially the same concept.
Why couldn't I classify all of these concepts as controllers? I feel like it might simplify the entire idea a great deal.
Can anyone give a clear description of their differences?
I want to clarify that I do understand how the patterns work, and have implemented most of them in one technology or another. What I am really looking for is someone's experience with one of these patterns, and why they would not consider their ViewModel a Controller for instance.
I'll give some reputation points for this, but I'm looking for a really good answer.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
除了已经提到的精彩读物（Fowler 和 Miller）以及回复您关于控制器/演示者/之间差异的观点之外......从开发人员的角度：
MVC 中的控制器:
控制器是由于用户交互而被调用的实际组件。开发人员不必编写代码来将调用委托给控制器。
控制器以某种方式从视图/上下文/包/任何东西获取当前值，但你不会真的说它与视图交互。
控制器最终决定向用户显示哪个视图。其中，控制器也显示了应用程序导航工作流程的明确概念。
MVP 中的 Presenter：
Presenter 具有由视图调用的方法，视图是在用户交互时接收控制的实际组件。开发人员必须在 View 中编写一些代码才能调用 Presenter。
Presenter 以某种方式从视图获取当前值，或者在调用时从视图接收它们。 Presenter 调用 View 上的方法来设置其状态（Josh Smith 说“填充它”）。 Presenter 调用的 View 方法可能在其主体中执行一些小设置。
Presenter 没有明确显示应用程序工作流程的概念。它通常被认为是将控制权返回给调用视图。
PM 中的PresentationModel：
PresentationModel 具有由视图调用的方法，视图是在用户交互时接收控制的实际组件。开发人员必须在视图中编写一些代码才能调用PresentationModel。
与 Presenter 相比，PresentationModel 与 View 之间的通信要频繁得多。它还包含更多逻辑，以便计算出要在视图中应用的所有设置的值，并在视图中实际设置这些设置。那些View方法依次几乎没有逻辑。
PresentationModel 没有明确显示应用程序工作流程的概念。它通常被认为是将控制权返回给调用视图。
MVVM 中的 ViewModel：
ViewModel 具有由 View 调用的方法（以及设置的属性），View 是在用户交互时接收控制的实际组件。开发人员必须在 View 中编写一些（声明性）代码才能调用 ViewModel。
与PresentationModel 相比，ViewModel 与View 之间没有明确的聊天通信（即，它不会频繁调用View，而是框架会调用）。但它有很多属性与视图设置一一映射。它仍然包含相同的逻辑来计算所有这些设置的值。
ViewModel 没有明确显示应用程序工作流程的概念。它通常被认为是将控制权返回给调用视图。
以某种方式复制 Josh Smith 所说的内容 (http://msdn.microsoft.com /en-us/magazine/dd419663.aspx)：MVVM 模式是 PM 的一种特殊情况，它利用框架（如 WPF/SL）来编写更少的代码。
Besides the already mentioned great reads (Fowler & Miller) and to reply to your point on differences among controller/ presenter/ ... from the developer's point of view:
Controller in MVC:
Controller is the actual component that gets called as a result of user interaction. Developer does not have to write code to delegate calls to the Controller.
Controller gets current values somehow from the View/ context/ bag/ whatever, but you would not really say that it interacts with the View.
Controller decides in the end which View to show back to the user. In that, Controller shows an explicit notion of application navigation workflow too.
Presenter in MVP:
Presenter has methods called by the View, which is the actual component receiving control upon user interaction. Developer has to write some code in the View in order to call the Presenter.
Presenter gets current values somehow from the View or receives them from the View upon call. Presenter calls methods on the View in order to set its state (populate it says Josh Smith). A View method called by the Presenter might have several small settings performed in its body.
Presenter does not explicitly show a notion of application workflow. It is usually thought of as returning control to the calling View.
PresentationModel in PM:
PresentationModel has methods called by the View, which is the actual component receiving control upon user interaction. Developer has to write some code in the View in order to call the PresentationModel.
PresentationModel has a much more chatty communication with View compared to a Presenter. It also contains more logic in order to figure out the value of all the settings to apply in the View, and to actually set those in the View. Those View methods in turns have almost no logic.
PresentationModel does not explicitly show a notion of application workflow. It is usually thought of as returning control to the calling View.
ViewModel in MVVM:
ViewModel has methods called (& properties set) by the View, which is the actual component receiving control upon user interaction. Developer has to write some (declarative) code in the View in order to call the ViewModel.
ViewModel has not an explicitly chatty communication with View compared to PresentationModel (i.e. it does not call View a lot, the framework does it). But it has a lot of properties that map 1 to 1 with View settings. It still contains the same logic to figure out the value of all those settings.
ViewModel does not explicitly show a notion of application workflow. It is usually thought of as returning control to the calling View.
Copying somehow what Josh Smith says (http://msdn.microsoft.com/en-us/magazine/dd419663.aspx): MVVM pattern is a special case of PM that takes advantage of a framework (like WPF/SL) in order to write less code.
Martin Fowler 有一个关于 UI 设计模式的页面，他在其中定义并讨论了 MVC、MVP 和其他模式。
http://martinfowler.com/eaaDev/uiArchs.html
控制器 主动控制 UI。例如，它将处理由 UI 触发的任何事件并适当地处理它们。
另一方面，Presenter 更加被动，只是通过 UI 显示数据，UI 处理它自己的事件等，或者通过 Presenter 将它们委托给服务或命令。
ViewModel 是 Presenter 的一个具体示例，设计用于与 WPF/Silverlight 绑定一起使用。
演示模型是可以直接由视图呈现的模型，因此，例如，如果您的模型实现 INotifyPropertyChanged 来进行数据绑定，那么它们将是演示模型。
Martin Fowler has a page on UI design patterns, in which he defines and then talks about MVC, MVP and other patterns.
http://martinfowler.com/eaaDev/uiArchs.html
A Controller is active in controlling the UI. For example it would handle any events triggered by the UI and deal with them appropriately.
A Presenter on the other hand is more passive, and simply displays data through the UI, which handles it's own events etc, or delegates them through the presenter to a service or command.
A ViewModel is a specific example of a Presenter, designed for use with WPF/Silverlight binding.
A Presentation Model is a model that can be presented directly by the view, so for example if your models implement INotifyPropertyChanged for data binding, they would be Presentation Models.
它们之间的区别本质上在于视图中有多少代码。它们之间的选择实际上是应用程序技术的选择，例如WFP、WinForms、ASP MVC(2)。将逻辑与表示分离的基本思想是相同的。
这里是关于这三个方面的非常好的文章。
编辑：
另一篇文章 - 比较。
The difference between them is essentially in how much code is in the view. The choice between them is in fact a choice of technology for application such as WFP, WinForms, ASP MVC(2). The basic idea of separating logic from presentation is the same.
Here is very good article about all three.
EDIT:
One more article - comparison.
在我看来，MVP、MVVC、MVC 和表示模型之间没有真正的概念差异。虽然存在一些细节差异，但最终，它们都可以继续被视为模型视图控制器设置。额外的命名只会造成混乱，我认为最好采用允许在描述控制器时有一定自由度的术语。
In my opinion, there are no real conceptual differences between MVP, MVVC, MVC and Presentation Model. There are some detailed differences, but in the end, it can all continue to be thought of as a Model View Controller setup. The extra naming just serves to create confusion, and I think it would be better to adopt terminology that allows for a certain amount of latitude in describing a controller.
MVP 和 MVVM 之间的一个重要区别是 VM 可以与许多视图一起使用，MVP 通常是 Presenter 和 View 之间的 1-1 关系，并具有强制执行其方法的契约接口。
Android 做了很多工作，将 MVVM 与构建在保留的 Fragment 之上的 ViewModel 组件结合起来。它是架构的首选模式，非常适合任何应用程序。
One important distinction between MVP and MVVM is that VM can be used with many views, MVP is usually 1-1 between Presenter and View with a contract interface that enforces its methods.
Android has done much to incorporate MVVM with the ViewModel component that is built on top of a retained Fragment. It is the pattern of choice for Architecture and well suited for any app.
至少在.Net中，MVP被用作一种设计模式。这通常与 Windows 窗体应用程序或经典 ASP.Net 一起使用。对于 MVC 和 MVVC，它们通常与 ASP MVC 一起使用，后者使用与普通 ASP.Net 完全不同的体系结构。
At least in .Net, MVP is used as a design pattern. This usually is used with Windows Forms applications, or classic ASP.Net . With MVC, and MVVC, these are usually used with ASP MVC, which uses a fairly different architecture than normal ASP.Net.