在 MVP 架构中存储状态的位置答案

【问题标题】：Where to store the state in a MVP architecture在 MVP 架构中存储状态的位置
【发布时间】：2010-08-17 16:37:22
【问题描述】：

在关于 SO 的其他 MVP 相关问题中，人们谈论 Presenter 保存状态信息（可能是会话状态或 UI 状态）。我想知道的是，既然状态基本上是“瞬态数据”，而模型的目的是封装数据访问，那么状态不能保存在模型内部吗？在 Presenter 和 Model 中存储状态是否有任何经验法则或优缺点？ MVP 模式是否要求使用 Presenter？

【问题讨论】：

标签： design-patterns language-agnostic mvp state

【解决方案1】：

模型的目的不是封装数据访问，而是提供您的域的表示（模型），无论它可能是什么。有时数据访问是模型的一部分（例如，Active Record 风格的数据访问），但通常它是分开的。例如，当我在桌面应用程序中完成 MVP 时，演示者直接从数据库中检索模型或使用 repository - 该模型与数据访问无关。

不过，在哪里存储与视图相关的状态是一个灰色地带，并且取决于您使用的应用程序类型 - 对于桌面应用程序，它更容易，因为您可以将其保存在演示器中，对于网络应用程序事情变得有点棘手。您可能会考虑为视图创建一个单独的模型，该模型可能包含也可能不包含核心模型（如 MVVM 模式中的 ViewModel，在 .Net WPF 开发中很流行）。

【讨论】：

是的，我正在为视图使用单独的模型。我将 MVP 严格应用于客户端。后端只是一个无状态的服务，与 UI 没有任何关系。
但它是视图的模型（例如，公开视图上的相同字段），还是只是表示层上使用的域模型的副本？如果它纯粹是视图的模型，我会说它比 MVP 更 MVVM - 虽然我还没有听说在 WPF 之外使用它，但我想没有理由不这样做。在这种情况下，是的，似乎是保留状态视图数据的公平场所。如果它是用于视图的域模型的副本，那么我会说演示者应该处理它（不知何故..）。（我假设这里的数据不是您通常存储在模型中的数据）。
我认为我想做的更像是 MVVM，因为我所说的“状态”纯粹是为了视图的当前状态。你提出了一些让我意识到这一点的好观点。谢谢！

【解决方案2】：

如果 state 直接与 View 绑定，那么 Presenter 就是合适的位置。

如果不是，Model 可能是合适的位置，但 Presenter 在某些情况下可能是合适的。

这里的关键是 View 和 Presenter 在概念上是耦合在一起的 - 虽然 Presenter 可能不知道特定的 View，但通常它必须为它所服务的 View 公开特定的数据。

【讨论】：