Session State with MVP and Application Controller patterns

Question

Hi,

I've created an MVP (passive view) framework for development and decided to go for an Application Controller pattern to manage the navigation between views. This is targeted at WinForms, ASP.NET and WPF interfaces.

Although I'm not 100% convinced that these view technologies really swappable, that's my aim at the moment so my MVP framework is quite lightweight.

What I'm struggling to fit in is the concept of a "Business Conversation" that needs state information to be either (a) maintained for the lifetime of the View or, more likely, (b) maintained across several views for the lifetime of a use case (business conversation). I want state management to be part of the framework as I don't want developers to worry about it. All they need to do is to "start" a conversation, "Register" objects and the framework does the rest until the "end" a conversation.

Has anybody got any thoughts (patterns) to how to fit this into MVP? I was thinking it may be part of the Application Controller responsibility (delegating to a Conversation Manager object) as it knows about current state in order to send the user to the next view.... but then I thought it may be up to the Presenter to start and end the conversation so then it comes down the presenters to manage conversations and the objects registered for the that conversation. Unfortunately that means presenters can't be used in different conversations... so that idea doesn't seem right.

As you can see, I don't think there is an easy answer (and I've looked for a while). So anybody else got any thoughts?

Answer 1

The classes needed to support a Business Conversation should reside in a presenter if it only involves the User Interface. Otherwise it should be in the Model and controller from the View to the Presenter to the Model. With information about Business Conversations flowing the other way. I suspect is something that can reside just in the Presenter.

Since all Views have access to the Presenter you then have the ability to structure the objects supporting the conversation so that they can be maintained across several views.

Remember Views are a window into what data resides in your software. They did little other display data and pass user interactions back into the presenter which does the logic.