2.5.7 Presenter First

More than a design, Presenter First is a discipline for coding a Dolphin MVP. As briefly stated in the closing remarks of the previous section, it is possible to deploy a Dolphin MVP variation where the View is fully passive.

The presenter performs calls on both the model and the new, and receives events from either of them.

Presenter First takes advantage of this choice to focus on the Presenter as the starting point for development of a specific triad. The idea is that, by creating the Presenter under direction of the customer’s desires, there’s a chance to progressively discover the required interfaces of both the View and the Model by coding against mocks and lastly implementing the discovered interfaces.

The point of presenter first is to code the presenter to satisfy customer needs, and code against it first. While the model provides a functionality and data oriented access, the presenter describes the actions in terms the user understands or specifies. The presenter has no state. It relies on the view and on the model to hold state, performing operations on these two. In principle, the Presenter should listen to events from either the model or the view, meaning that it should not need public methods. All the connections between events and presenter methods are setup by the presenter itself.

The Presenter should be tested strenously. The View, being a Humble View, can be left untested.