Why state cannot be part of Presenter in MVP?

Question

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

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.

I wonder why Presenter can't hold View state? It already holds all View logic.

As far as I understand, in MVC and MVP the state is kept in View. In PM and MVVM the state is kept in the Presentation Model. Why can't Presenter follow PM in this particular case and contain the state of the view?

Here is another article which says Presenter does not hold View state, instead the view does: http://www.codeproject.com/KB/aspnet/ArchitectureComparison.aspx

Answer 1

I think you are absolutely right when you say the view stores the view state in MVP: it's simply the way "concerns are separated" in MVP. In "clean MVP" view state is kept in the view and not in the presenter. The presenter can query the view for it's state using the methods provided by the view's interface.

Keeping state in the presenter will make your presenter a hybrid between presentation model and presenter. Be pragmatic and don't rebuild your complete app if you find yourself keeping some view state in the presenter sometimes.

Just be aware of the general motivations to use either the PM or MVP patterns.

On Fowler's eeaDev web article on Presentation Model he states:

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.

Fowler continues:

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.

I disagree with the statement you quote in your question:

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

It isn't a problem: it's a choice. IMO Fowler does not mention this "persistence of view state" as a motivation to use Presentation Model instead of MVP, be it Supervising Controller or Passive View.

I'm not quite sure if Fowler with "to store state" means persistence in the sense of "across application life time". But regardless, the point is it's a choice with a trade off: when you use Presentation Model instead of MVP, you get

• better testability of view state
• independence of view with regard to (storing) view state
• "programmer" can create PM and "UI designer" can then separately work on view

at the expense of

• having to sync the view with the presentation model

Note that the latter "expense" maybe less nowadays than at the time of Fowler's writing (2006), because of modern UI synchronization techniques, such as .NET's data binding.