Why can't state be part of Presenter in MVP?

Question

I read http://www.codeproject.com/KB/architecture/MVC_MVP_MVVM_design.aspx and said:

As powerful as MVC and MVP have their problems. One of them is the persistence of the Views state. For example, if the Model, being a domain object, knows nothing about the user interface, and the view does not implement any business logic, then where will we store the state of the View items, such as selected Items? Fowler comes up with a solution in the form of a presentation model template.

I wonder why Presenter cannot hold View state? It already contains all the View logic.

As far as I understand, in MVC and MVP the state is saved in the view. In PM and MVVM, state is stored in the view model. Why in this particular case, Presenter cannot follow PM, and contain view state?

Here's another article that says Presenter doesn't support View state, instead looks like this: http://www.codeproject.com/KB/aspnet/ArchitectureComparison.aspx

Answer 1

I think that you are absolutely right when you say that a view stores the state of a view in MVP: this is just a way to "separate problems" in MVP. In the "pure MVP" state, the view state is saved, not in the presenter. The facilitator can request a presentation for him using the methods provided by the presentation interface.

Preserving state in the presenter will make your presenter a hybrid between the presentation model and the presenter. Be pragmatic and do not rebuild your full application if you sometimes find that some state of presentation is in the presenter.

Just keep in mind the general motivation for using PM or MVP patterns.

In the Fowler eeaDev web article on the presentation model, he states:

A presentation model is a template that draws presentation behavior from a view. Thus, it is an alternative to the Supervisory Controller and Passive View. This is useful for a test without a user interface, support for some form of multiple viewing and separation of problems that may make it easier to develop a user interface.

Fowler continues:

Compared to the passive presentation and the Controlling controller, the 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 a view to maintain state. The disadvantage is that you need a synchronization mechanism between the presentation model and the presentation.

I do not agree with the statement that you quote in your question:

One of the [problems of MVP] is maintaining state of views.

This is not a problem: it is a choice. IMO Fowler does not mention this “persistence of presentation state” as a motivation to use the Presentation Model instead of MVP, whether it be a Controlling Controller or Passive View .

I'm not quite sure that Fowler with “store state" means constancy in the sense of "application lifetime". But regardless of whether it is worth choosing with a compromise: when you use the Presentation Model instead of MVP, you get

• better verifiability of view state
• independence of representation regarding storage (storage) status
• a "programmer" can create PM, and a "UI designer" can then work separately in a view

due to

• the need to synchronize the presentation with the presentation model

Note that the last “expense” may be less these days than when Fowler (2006) wrote, due to modern user interface synchronization methods such as .NET data binding.