Menu
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?
631
The presenter gets and sets information from/to the view through an interface that can be accessed by the interface (view) component. In addition to manually implementing the pattern, a model-view-presenter framework may be used to support the MVP pattern in a more automated fashion.
Key Points of MVP Architecture Communication between View-Presenter and Presenter-Model happens via an interface(also called Contract). One Presenter class manages one View at a time i.e., there is a one-to-one relationship between Presenter and View.
What is MVP? The MVP pattern allows separating the presentation layer from the logic so that everything about how the UI works is agnostic from how we represent it on screen. Ideally, the MVP pattern would achieve that the same logic might have completely different and interchangeable views.
Presenters are used to hide implementation details from views. They serve as a go-between for controllers and views. Presenters provide access to controller instance variables. @presenter should be the only instance variable accessed in the view.
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).
153
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.
4
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
