当前位置：文江博客话题详情

什么是 MVP-被动视图和 MVP-监督控制器

发布于 2024-10-25 03:11:43 字数 119 浏览 1 评论 0原文

请用一个简单的例子来描述 MVP-Passive View 和 MVP-Supervising Controller 之间的区别。最好展示如何使用 mvp 技术（被动视图和监督控制器）绑定带有控制的数据以及如何验证输入。谢谢

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

万劫不复 2024-11-01 03:11:43

区别在于视图层更新。

从 MSDN 上的模型-视图-演示者模式页面：

更新模型时，视图也必须更新以反映更改。可以通过多种方式处理视图更新。模型-视图-呈现器变体、被动视图和监督控制器指定了实现视图更新的不同方法。
在被动视图中，演示者更新视图以反映模型中的更改。与模型的交互完全由演示者处理；视图不知道模型中的更改。
在监督控制器中，视图直接与模型交互，以执行可以以声明方式定义的简单数据绑定，无需演示者干预。演示者更新模型；仅在需要无法以声明方式指定的复杂 UI 逻辑的情况下，它才会操作视图的状态。复杂 UI 逻辑的示例可能包括更改控件的颜色或动态隐藏/显示控件。图 1 说明了被动视图和监督控制器变体的逻辑视图。
决定使用被动视图还是监督控制器主要取决于您希望应用程序的可测试性。如果可测试性是应用程序中的主要关注点，被动视图可能更合适，因为您可以通过测试演示器来测试所有 UI 逻辑。另一方面，如果您更喜欢代码简单性而不是完整的可测试性，那么监督控制器可能是更好的选择，因为对于简单的 UI 更改，您不必在演示器中包含更新视图的代码。在被动视图和监督控制器之间进行选择时，请考虑以下因素：
这两种变体都可以让您提高表示逻辑的可测试性。
被动视图通常提供比监督控制器更大的测试面，因为所有视图更新逻辑都放置在演示器中。
监督控制器通常比被动视图需要更少的代码，因为演示者不执行简单的视图更新。

进一步阅读：

被动视图

http://martinfowler.com/eaaDev/PassiveScreen。 html

http://codebetter.com/jeremymiller/2007/05/31/build-your-own-cab-part-4-the-passive-view/

监督控制器：

< a href="http://martinfowler.com/eaaDev/SupervisingPresenter.html" rel="noreferrer">http://martinfowler.com/eaaDev/SupervisingPresenter.html

http://codebetter.com/jeremymiller/2007 /05/25/build-you-own-cab-part-3-the-supervising-controller-pattern/

The difference is in view layer updates.

From the Model-View-Presenter pattern page on MSDN:

When the model is updated, the view also has to be updated to reflect the changes. View updates can be handled in several ways. The Model-View-Presenter variants, Passive View and Supervising Controller, specify different approaches to implementing view updates.
In Passive View, the presenter updates the view to reflect changes in the model. The interaction with the model is handled exclusively by the presenter; the view is not aware of changes in the model.
In Supervising Controller, the view interacts directly with the model to perform simple data-binding that can be defined declaratively, without presenter intervention. The presenter updates the model; it manipulates the state of the view only in cases where complex UI logic that cannot be specified declaratively is required. Examples of complex UI logic might include changing the color of a control or dynamically hiding/showing controls. Figure 1 illustrates the logical view of the Passive View and Supervising Controller variants.
The decision to use Passive View or Supervising Controller primarily depends on how testable you want your application to be. If testability is a primary concern in your application, Passive View might be more suitable because you can test all the UI logic by testing the presenter. On the other hand, if you prefer code simplicity over full testability, Supervising Controller might be a better option because, for simple UI changes, you do not have to include code in the presenter that updates the view. When choosing between Passive View and Supervising Controller, consider the following:
Both variants allow you to increase the testability of your presentation logic.
Passive View usually provides a larger testing surface than Supervising Controller because all the view update logic is placed in the presenter.
Supervising Controller typically requires less code than Passive View because the presenter does not perform simple view updates.