I am using the Model-View-Presenter pattern for a web page. Should the presenter be aware of Session or should only the view be aware of it?
I guess what I am getting at is that concepts like Session are very related to the architecture of the view so should they be limited to use by the view? Otherwise what would happen if I wanted to reuse the presenter on a similar page on a different architecture (or do I not need to worry about that unless I have plans to do so)?
I am doing something like this in my MVP Implementation I inject an ICookieManager, ISessionManager, ICacheManager, IConfigurationManager, IRedirector into my presenter which are implemented by classes that wrap the functionality for this.
This allows for a presenter where you can inject mocked versions of these in and you have no direct dependancies on the asp.net runtime in your presenter so it makes testing easier.
Cheers
It could even be a shared module that acts as a wrapper into whichever session you are using. This way it would be available to all your controllers and you could change the physical implementation of the session simply.
Your presenter would fill the view with whatever the controller fetched from the session.
Thanks for your answers everyone, so to summarise...
Are we saying that actually the Presenter should be able to access data from session (preferably via an interface) and its the view that should not access it (remaining dumb)?
Depends which object you're trying to re-use or otherwise contains most of the business logic.
I would assume only the presenter should know of the session as that object is the closest thing to a controller in MVP.
Yes, as dove says, wrap whatever accesses the Session in another class.
This means that you could inject a mock class of this type to simulate different values for Session.
To answer your question more specifically, I tend to go for the Supervising-Presenter pattern (http://martinfowler.com/eaaDev/SupervisingPresenter.html), which keeps the Views as VERY dumb. So only the Presenter would access the Session (though not directly as I said before) and tell the View what to do.
I'm researching passive MVP approaches, too. I've seen a couple of things done on the web, both of which leave session persistence up to the view - either through injection, as dove mentioned, or explicit management.
Dependency Injection examples can be seen here: http://www.codeproject.com/KB/aspnet/Advanced_MVP.aspx and here: http://geekswithblogs.net/opiesblog/archive/2006/06/30/83743.aspx. The trick here is to manage all of the session instances in a static variable, and prevent them from overwriting each other. (I'm not sure the first example accomplishes this properly.)
The second approach is here: http://codebetter.com/blogs/jeffrey.palermo/archive/2005/03/28/128592.aspx. In this example the view knows how to store its state. The downside is that every time the presenter puts data into the view it must call an Update method on the view to force rebinding. This isn't needed in the examples above, but you don't need to manage a table of sessions. I'm not sure how this approach complicates testing with mocking tools.
The tip is to interface every consumable entity. It makes the presenter and the model easier to test with mocking and focus the tests on behavior.
