In other MVP-related questions on SO, people talk about the Presenter keeping the state information (could be session state or UI state). What I'm wondering is, since state is basically "transient data", and the Model's purpose is to encapsulate data access, can't state be kept inside the Model? Are there any rules of thumb or pros/cons around storing the state in the Presenter versus the Model? Does the MVP pattern mandate the use of the Presenter?
+2
A:
If the state is directly tied to the View, then the Presenter is the appropriate place.
If not, the Model is likely the appropriate place, but the Presenter may be appropriate in some cases.
They key here is that the View and Presenter are conceptually coupled together - while the Presenter may not know about the specific View, generally it will have to expose specific data for the View it is servicing.
kyoryu
2010-08-17 16:57:04
+2
A:
The model's purpose isn't to encapsulate data access, it's to provide a representation (model) of your domain, whatever that may be. Sometimes data access is included as part of the model (e.g. with Active Record style data access), but more often than not it's separate. When I've done MVP in desktop apps, for example, the presenter retrieved the model from the database directly or using a repository - the model wasn't anything to do with data access.
Where to store view-related state is a bit of a grey area though, and depends on what type of app you're using - for desktop apps it's much easier as you can just keep it in the presenter, for web apps things get a bit more tricky. You might consider a separate model for the view, which may or may not wrap the core model (as in the ViewModel in the MVVM pattern, popular in .Net WPF development).
Grant Crofton
2010-08-17 17:10:58
Yes, I'm using a separate model for the view. I'm applying MVP strictly for the client-side. The back-end is just a stateless service and has no relation with the UI.
Ates Goral
2010-08-17 20:16:42
But is it a model of the view (e.g. exposes the same fields that you have on the view), or just a copy of the domain model which is used on the presentation layer? If it's purely a model of the view, I'd say that was more MVVM than MVP - while I haven't heard of this being used outside WPF, I suppose there's no reason why not. In which case yeah, seems a fair place to keep stateful view data. If it's a copy of the domain model which is used for the view, then I'd say the presenter should handle it (somehow..). (I'm assuming here the data is not what you'd normally store in the model).
Grant Crofton
2010-08-18 10:19:39
I think what I'm trying to do is more like MVVM because the "state" I'm talking about is purely for the current state of the View. You raised some good points that made me realize this. Thank you!
Ates Goral
2010-08-18 15:50:20