我看了http://www.codeproject.com/KB/architecture/MVC_MVP_MVVM_design.aspx并说：
同样强大，无论是MVC还是 MVP有他们的问题。其中之一 是视图状态的持久性。 例如，如果模型，是一个 域对象，什么都不知道 关于UI，而View没有 然后实现任何业务逻辑 我们在哪里存储的状态 查看选中的元素 项目？福勒提出了一个解决方案 以演示模型的形式 图案。
我想知道为什么Presenter无法保持View状态？它已经拥有所有View逻辑。
据我了解，在MVC和MVP中，状态保持在View中。在PM和MVVM中，状态保存在Presentation Model中。为什么Presenter在这种特殊情况下不能跟踪PM并包含视图的状态？
这是另一篇文章，其中说Presenter不支持View状态，而是视图执行：http://www.codeproject.com/KB/aspnet/ArchitectureComparison.aspx
答案 0 :(得分：7)
当你说视图将视图状态存储在MVP中时，我认为你是完全正确的：它只是MVP中“关注点被分离”的方式。在“干净的MVP”中，视图状态保留在视图中而不是在演示者中。演示者可以使用视图界面提供的方法查询视图的状态。
在演示者中保持状态将使演示者成为演示模型和演示者之间的混合体。务实，如果您发现自己有时在演示者中保留一些视图状态，请不要重建您的完整应用程序。
请注意使用PM或MVP模式的一般动机。
在Fowler的eeaDev web article on Presentation Model中他说：
Presentation Model是一种模式 拉动演示行为 视图。因此，它是一种替代品 监督控制器和被动 视图。这对你来说很有帮助 测试没有用户界面，支持一些 多视图和分离的形式 令人担忧的问题可能会更容易 开发用户界面。
福勒继续说道：
与被动视图和。相比 监督控制器，演示 Model允许你编写逻辑 完全独立于观点 用于显示。您也不需要依赖视图来存储状态。 缺点是你需要一个 之间的同步机制 演示模型和视图。
我不同意你在问题中引用的陈述：
MVP的一个问题是View状态的持久性。
这不是问题：这是一个选择。 IMO Fowler没有提到这种“视图状态持久性”作为动机使用Presentation Model而不是MVP，无论是Supervising Controller还是Passive View。
我不太确定Fowler是否具有“存储状态”意味着“跨越应用程序生命周期”的持久性。但无论如何，重点是它是一个权衡的选择：当你使用Presentation Model而不是MVP时，你得到了
以牺牲
为代价请注意，由于现代的UI同步技术，例如.NET的数据绑定，后者的“费用”现在可能比Fowler写作时（2006年）更少。