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

Question

我读了http://www.codeproject.com/KB/architecture/MVC_MVP_MVVM_design.aspx它说:

As powerful as they are, both MVC and MVP have their problems. One of them is persistence of the View’s state. For instance, if the Model, being a domain object, does not know anything about the UI, and the View does not implement any business logic, then where would we store the state of the View’s elements such as selected items? Fowler comes up with a solution in the form of a Presentation Model pattern.

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

据我了解，在 MVC 和 MVP 中，状态保持在 View 中。在 PM 和 MVVM 中，状态保存在 Presentation Model 中。为什么 Presenter 在这种特殊情况下不能跟随 PM 并包含 View 的状态？

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

Answer 1

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

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

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

在福勒的 eeaDev web article on Presentation Model他说:

Presentation Model is a pattern that pulls presentation behavior from a view. As such it's an alternative to to Supervising Controller and Passive View. It's useful for allowing you to test without the UI, support for some form of multiple view and a separation of concerns which may make it easier to develop the user interface.

福勒继续说道:

Compared to Passive View and Supervising Controller, Presentation Model allows you to write logic that is completely independent of the views used for display. You also do not need to rely on the view to store state. The downside is that you need a synchronization mechanism between the presentation model and the view.

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

One of [the problems of MVP] is persistence of the View’s state.

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

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

更好的 View 状态可测试性

关于(存储) View 状态的 View 独立性

“程序员”可以创建 PM，“UI 设计师”可以分别在 View 上工作

以......为代价

必须将 View 与演示模型同步

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