What's a good practice for dividing up presenters in a MVP interface pattern that have grown to large?

Question

One problem that I have frequently run into lately is the problem of my presenter classes growing too large. Usually, I can chop up a regular large class without skipping a beat. But the presenters sometimes are a little more difficult to pare down, without making the code harder to follow.

Especially when the page starts filling up with CRUD oriented controls. Sometimes I divide out controls, but if they are affected by other controls the coordination logic is complex in it's own right. Sometimes I divide out list or grid data retrieval, but sometimes that can have similar pitfalls.

Are there any techniques, or rules of thumb, or common areas that you refactor out of your presenters?

Any advice?

Thanks!

Answer 1

Try to extract the code that performs activity outside of passing data to your DAL or pushing it to the view. For instance, if you have to do email updates or perform business logic, try to extract those out into separate classes. I often deal with the same problem and have been trying to move as much logic as possible to the individual domain/entity classes and perform validation there.

Hope this is helpful.

Answer 2

I usually use two approaches:

1. Extract and delegate business rules to domain classes.
2. Partition the view into logically related controls then create a new view interface for each partition. You can then split your presenter along those same lines. If the platform your using supports subform component groups (C# user controls, Delphi frames, etc) this is a powerful way to make reusable controls.

Update

When splitting views, I typically start by splitting the interface and having my form implement multiple interfaces.

public class ComplexForm: Form, ISubView, IOtherSubView
{
    ...
}

Then I split the presenter into however many views I've created.

public class SubViewPresenter
{
    private ISubView subView;
    ...
}

public class OtherSubViewPresenter
{
    private IOtherSubView otherSubView;
    ...
}

You can go a step further and move the implementation of ISubView and IOtherSubView to user controls or leave it as-is. If you're using a passive view pattern this is child's play since the form only handles UI logic anyway. Once I split the presenter, I try to avoid direct communication between presenters. If any communication is needed I try to do it indirectly through domain objects.