views:

792

answers:

4

As I understand, when we use MVP we move all presentation logic to the Presenter. But we don't want to let the Presenter know about view implementation, so how can we navigate to another screen in the application? How do you manage application flow on your real application?

A: 

It's a Method on the view. So you would have an abstract method, like ShowCustomerForm(), for example, and the implementation for WinForms would be CustomerForm.Show (or whatever it is in WinForms) and in WebForms it would be Response.Redirict(CustomerForm.aspx).

Charles Graham
+2  A: 

Using some navigator interface, for example:

interface INavigator
{
    void MoveTo (string screenName);
    void MoveTo (string screenName, NavigationParameters parameters);
}

Each presenter would then have an instance of this navigator passed in the constructor. This way the navigation is decoupled both from the presenter and from individual views.

You can have the mapping between screen names and actual Form classes defined in a configuration.

Igor Brejc
A: 

I assume that you mean another screen that has its own MVP-pair?

I was thinking about that case this morning, my solution will probably be that there is a Coordinator knows the Presenter and the MVP-pair that needs to be opened. That one opens the new presenter+view and, when finished, optionally calls a method on the first presenter with the results.

In that way, the first MVP doesn't have to know anything about the new screen, they only fire an event. The logic for opening the second window and communicating back is entirely contained in the Coordinator.

Lennaert
A: 

We do this using what Lennaert calls a coordinator (we call this a workflowcontroller). I come from Java web development and the idea was a form of ApplicactionController. I've run into some issues with this, the workflowcontroller runs a command. Each command represents a workflow or a series of related steps (thus the name workflowcontroller). The flowcontroller handles the naviagation between commands and a flowcontroller has a navigator that navigates between the steps. Each step has a finish event (which the presenter gets wired to) and NextStep Method that we use to navigate to the next step. Our worflowcontroller is tightly coupled to the menu so we can navigate between different workflows The steps establish the link between view and presenters. We don't have any configuration and have hardwired the logic that establishes the next step to execute into a method called NextStep. It is in production, but I'm not very satisfied with this. Too much detail to get into here. I've thought about shifing to something that is more event driven. We use a message bus to do all of our other communication and I'd like to shift to using this to navigate between screens. I don't know if that would be helpful or not. our screens for the most part consist of sequential workflows.