Understanding View Events in the MVP Pattern

Being that I've been undertaking several Model-View-Presenter projects, I'm writing this post to illustrate the way a view uses an event.  In the Model View Presenter pattern, the primary means a view communicates with the presenter is using events.  Methods of the view can be called from the presenter, but typically I've seen mostly events.  An event signals that some action is happening within the system.  The user saved a record, selected an object, cancelled their changes, etc.   These actions translate from a button click, etc. in the UI to the view passing up a corresponding event to the presenter.  The presenter only knows about the view's events through the view's interface, which, of course, the view has to implement.  Since the view is required to implement X event, X event can be listened to in the presenter, and this completes the first round of the process.

Be careful that you understand the reasoning for the event; the event is not used solely to serve the presenter.  For instance, if the view attempts to load data on demand solely for pushing data to the view, its not the responsibility of the view to do this necessarily; the presenter is the controller driving what happens during the request; the view is responsible for managing the UI.

For instance, suppose that this happened in the view:

protected override void OnLoadReferenceData(EventArgs e)
{
    var args = new DataEventArgs();
    if (LoadReferenceData != null)
        LoadReferenceData(args);

    //Commence with loading the data here
}

In this example, who is in control of the process?  The presenter is supposed to be in control, but the view oversteps its bounds and starts making demands for its needs.  In this way, we can circumvent the presenter from performing the responsibilities it is supposed to be performing.  This is especially true if we see many On<X> methods, each loading a portion of its data.  Why do I say this?  The presenter can become a data access class, primarily serving the view, rather than controlling the flow of the process, and having the presenter load and push down data at the right time through the model.

Playing devil's advocate, can there be times when view loading of demand is needed?  Certainly.  Can a view load the data directly from event args, instead of the model.  Sure, however, I would recommend to leave the presenter as the sole responsibility over the process, otherwise the view and presenter may become chaotic to maintain.

So what is essentially the difference between the two?  On one level, its grammar.  A view event named RefreshPage appears differently to the user than LoadData or NeedData.  It can also be by action; if the view fires an event and immediately loads its data from the event args, then what is the presenter really doing?  Is it controlling the process, or is it a data access layer?  Does the view respond to the model passed from the presenter?  This is a proper way for the communication chanel.

Some food for thought.  I would love to hear your opinion.  Please comment using the form below.