为什么状态不能成为 MVP 中 Presenter 的一部分？答案

【问题标题】：Why state cannot be part of Presenter in MVP?为什么状态不能成为 MVP 中 Presenter 的一部分？
【发布时间】：2011-06-23 15:35:27
【问题描述】：

尽管 MVC 和 MVP有他们的问题。其中之一是视图状态的持久化。例如，如果模型是领域对象，什么都不知道关于 UI，而 View 没有实现任何业务逻辑，然后我们将在哪里存储状态 View 的元素，例如 selected 项目？福勒想出了一个解决方案以演示模型的形式模式。

我想知道为什么 Presenter 不能保持 View 状态？它已经包含了所有的 View 逻辑。

据我了解，在 MVC 和 MVP 中，状态保留在 View 中。在 PM 和 MVVM 中，状态保存在表示模型中。为什么 Presenter 在这种特殊情况下不能跟随 PM 并包含视图的状态？

这是另一篇文章，它说 Presenter 不保持 View 状态，而是 View 保持：http://www.codeproject.com/KB/aspnet/ArchitectureComparison.aspx

【问题讨论】：

它打破了模式。 WPF 的强大功能通过DataTemplates 加以利用。视图“查看”数据类型并“膨胀”到其定义的 DataTemplate。 MVP 还允许“视图优先”的方法；这使得从定义的 ViewModel 更改 View 变得更容易。示例：如果您的 ViewModel 公开 IList 客户，您可以轻松更改您的视图，而不是更改您的视图和控制器 (MVC)。
我不同意它不应该“存储视图元素的状态，例如所选项目”的说法。许多属性可以是模型的一部分，有助于保存视图状态，例如“IsSelected”属性，而不会破坏模式。
在你提到的first article的总结中，作者指出：“MVP 将更多的工作委托给 View 并移除了 Controller。它引入了 Presenter 类，封装了 View 的状态和命令。”所以文章中似乎存在矛盾。
@Marijn 是的，我两天前才注意到。我不知道该怎么想。你认为状态应该在 Presenter 中吗？
在干净的 MVP 中你不需要；我更新了我的答案，试图更清楚地反映这一点。

【解决方案1】：

当您说视图在 MVP 中存储视图状态时，我认为您是绝对正确的：这只是 MVP 中“关注点分离”的方式。在“干净的 MVP”视图中，视图状态保留在视图中，而不是在演示者中。演示者可以使用视图接口提供的方法查询视图的状态。

在演示者中保持状态将使演示者成为演示模型和演示者的混合体。如果您发现自己有时会在演示者中保留一些视图状态，请务实，不要重新构建完整的应用程序。

请注意使用 PM 或 MVP 模式的一般动机。

Presentation Model 是一种模式从看法。因此，它可以替代到监督控制器和被动看法。它有助于让您无UI测试，支持一些多视图和分离的形式可能会使事情变得更容易的担忧开发用户界面。

福勒继续：

与被动视图相比监督控制器，演示模型允许您编写逻辑完全独立于视图用于展示。您也不需要依赖视图来存储状态。缺点是你需要一个之间的同步机制表示模型和视图。

我不同意您在问题中引用的陈述：

[MVP 的问题] 之一是 View 状态的持久性。

这不是问题：这是一种选择。 IMO Fowler 没有提到这种“视图状态的持久性”作为使用 Presentation Model 而不是 MVP 的动机，无论是 Supervising Controller 或 Passive View。

我不太确定 Fowler 的“存储状态”是否意味着“跨应用程序生命周期”意义上的持久性。但无论如何，关键是它是一个权衡的选择：当你使用 Presentation Model 而不是 MVP 时，你会得到 p>

以牺牲

为代价

请注意，由于现代 UI 同步技术（例如 .NET 的数据绑定），如今后者的“费用”可能比 Fowler 写作时（2006 年）时要少。

【讨论】：