演示者，演示模型，ViewModel和控制器之间有什么区别？ [英] What are the differences between Presenter, Presentation Model, ViewModel and Controller?

问题描述

我有一个很好的想法，每个这些模式如何工作，并了解他们之间的一些细微的差异，但是他们真的有所不同吗？

在我看来，Presenter，Presentation Model，ViewModel和Controller本质上是一样的概念。

为什么我无法将所有这些概念分类为控制器？我觉得这可能会简化整个想法很多。

任何人都可以清楚地描述他们的差异？

我想澄清一点，我明白了这种模式是如何工作的，并且通过一种技术实现了大部分技术。我真正寻找的是某人对这些模式之一的体验，为什么他们不会考虑他们的ViewModel控制器。

我会给一些声望点为此，我正在寻找一个非常好的答案。

解决方案

除了已经提到的伟大的阅读（Fowler& Miller ），并从开发者的观点来回答您对控制器/演示者/ ... 之间差异的观点：

控制器在MVC中：

• 控制器是由于用户交互而被调用的实际组件。 （开发人员不必编写代码来调用Controller）。




• 控制器从View / context / bag / any中获取当前值，但是你不会真的说它与视图交互。



• 控制器决定到底向哪个视图显示给用户。在这一点上，Controller显示了应用程序导航工作流的明确概念。

MVP中的演示者：

• 演示者具有由View调用的方法，这是用户交互时实际的组件接收控制。 （开发人员必须在视图中编写一些代码才能调用Presenter。）




• 演示者从视图中获取当前值，或从视图接收它们随叫随到。主持人在视图中调用方法，以设置其状态（填充 Josh Smith）。由Presenter 调用的View方法可能在其正文中执行了几个小的设置。




• 演示者没有明确显示应用程序工作流程的概念。通常被认为是调用View的返回控件。

PM中的PresentationModel ：

• PresentationModel具有由View调用的方法，它是用户交互后实际的组件接收控制。 （开发人员必须在视图中编写一些代码才能调用PresentationModel。）




• PresentationModel具有更多的聊天通信与观众相比，演示者。它还包含更多的逻辑，以便找出要在View中应用的所有设置的值，并在View中实际设置这些值。 （那些View方法根本就没有逻辑）。




• PresentationModel没有明确显示应用程序工作流的概念。通常被认为是调用View的返回控件。

MVVM中的ViewModel ：

• ViewModel具有通过View调用（&属性集）的方法，这是用户交互时实际的组件接收控制。 （开发人员必须在视图中编写一些（声明性）代码才能调用ViewModel。）




• ViewModel与View没有明确的聊天通信PresentationModel（即它不调用View，很多框架）。但是它具有很多属性，可以通过查看设置将1映射到1。它仍然包含相同的逻辑来计算所有这些设置的值。




• ViewModel没有明确显示应用程序工作流程的概念。通常被认为是调用View的返回控件。




• 不知何故复制乔什史密斯（ http://msdn.microsoft.com/en-us/magazine/dd419663.aspx ）：MVVM模式是利用框架（如WPF / SL）的一种特殊情况）以便编写较少的代码。

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.

解决方案

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 receive 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.

这篇关于演示者，演示模型，ViewModel和控制器之间有什么区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！