Search code examples
design-patternslanguage-agnosticmvpstate

Where to store the state in a MVP architecture


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?


Solution

  • 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).