views:

426

answers:

3

I am trying to implement the MVP pattern for WINFORMS. Its a simple for with a button and a Grid, on button click, the grid will load, and user can fill in values into the grid.

For my button click event, I have something like this:

_presenter.LoadGrid();

Which is simple and straightforward.

My question is, in regards to grid... I am planning to have a row click event firing....for enabling/disabling the subsequent input fields for the specific columns/rows of the grid etc.

I understand that the presenter should not contain any GUI elements and the View(form) shouldn't really contain Logic?

So, to have that GridRowClick event firing, I need to manipulate the grid (GUI) based on business rules (Logic). I am lost between letting the presenter handle the logic of that click event or the form?

If the presenter is to handle the click event, wont that include the gui components? If the view is to handle the click event, the fieldnames etc are all business driven(logic), dynamically binded based on datatable returned from the business layer.

Any advice will be much appreciated.

Cheers

A: 

The key is getting all that business logic into the presenter where it's testable.

The view should call the presenter to perform the business logic, passing the information needed (e.g. the data associated with the clicked row).

The presenter then performs the business logic and updates the data.

Depending on what type of changes you need to make, that might be all you need to do, since the existing data binding might be sufficient to update the view automatically. If it isn't sufficient, the presenter can make one or more calls to the view (via its interface of course) in order to make the required changes.

As you say, you should aim to minimize the amount of non-trivial code in your view, and in particular, the view shouldn't have any business logic in it.

EDIT:

Some good general information on MVP and other presentation patterns here: http://martinfowler.com/eaaDev/uiArchs.html

Dave Cluderay
+1  A: 

There are (at least) two variants of MVP.

  • Passive View Pattern
  • Supervising Controller Pattern

Passive View, as its name suggests, treats the UI as a more or less passive interface between the user and the application. It moves as much testable code to the presenter as possible leaving the view to handle only the most basic UI updates.

Supervising controller gives the view a little more responsibility by letting it handle data synchronization. This is usually done through data binding.

In either case event handling is accomplished by delegating to a presenter method:

EventHandler()
{
    presenter.HandleEvent();
}

If handling the event requires making changes to the form, you expose what needs to be updated as a property:

public string PropertyThatNeedsToBeUpdated
{
    get
    {
        return Control.Property;
    }
    set
    {
        Control.Property = value;
    }
}

For Passive View, grids are a hurdle. Their complexity make it cumbersome to capture all the possible events. With Supervising controller, grids are much easier since you leave data synchronization up to the data bound controls.

You have to make the judgment call as to which is more appropriate for your situation.

codeelegance
A: 

You might want to check out Part 4 of the video series from Polymorphic Podcast. He uses the supervising controller pattern and shows a technique for handling data grids. The whole series was actually a good introduction for me.

http://polymorphicpodcast.com/shows/mv-patterns/

Keith G