MVP and UserControls and invocation

Question

I'm having some fun trying to get my head around some MVP stuf, as it pertains to User Controls. I'm using .NET WinForms (or something close to it) and Supervising Controller pattern (well, I think I am :).

The User Control is itself part of an MVP application (its the View and has an associated Presenter etc). The Presenter is always started first, and it starts the Model(s) and then View(s). The View builds its UI, part of which will be to NEW the UC, which is the View.

Now the (form) Presenter needs to know about the UC Presenter, but I'm thinking that it doesn't know anything about how the View is composed. The form Presenter doesn't, for instance, know that the UC is part of the form's Controls collection, nor should it.

Furthermore, the design experience should not be changed; IOW the dev of the View (form) should just be able to select a User Control from the toolbox and drop it on a form.

So, on to my questions. Firstly, are my assumptions above correct? Somewhat misguided? Messed up? WTF are you thinking?

Secondly, is it right (enough?) to have the form View invoke the UC View, and the form Presenter invoke the UC Presenter and have some mechanism to tell the UC View what its Presenter is? This breaks my "Presenter first" rule, but I'm not sure how else to do it.

Any other thoughts, suggestions, comments gladly accepted.

-- nwahmaet

Answer 1

A presenter should be thought of as "autonomous state" in the presentation tier. This means that it is responsible for ensuring that the view's presentation of the model's state is in sync. The reason I bring this up is because the "pattern" of MVP often gets lost in the dogmatic view of how things should be separated. It seems that this is one reason Martin Fowler decided to try to clarify the terminology around the MVP pattern.

My favored flavor of MVP is the passive view, so my answer is based off of that.

I implement composite user controls and forms very often using the passive view pattern. There are essentially 3 different configurations:

1. One presenter for all user controls in the hierarchy. Flatten the view using an interface.
2. One presenter for each user control in the composite tree. Each parent presenter is responsible for instantiating and initializing its child presenters. The user controls are created at design time, and are able to function without a presenter (with no presentation behavior)
3. One presenter for each user control in the composite tree. All of the presenters are loosely coupled through a higher level controller class. The controller class is responsible for construcing the presenter, wiring them up, and coordinating their events.

Although it is a solution of last resort for me (because of its complexity), I think that the last option is the solution that you are looking for.

Answer 2

I've been running up against this exact problem for several months in an application I'm working on. The conclusion that I've very recently come to is that in many cases it might be impossible to apply the MVP pattern at both the window AND user control levels, without "breaking" the pattern.

My thought on it is that the user control is part of the view implementation, and the presenter should not know what is going on inside the view implementation, which means that the window-level presenter by extension should not know about the user control's presenter, and hence there should be no communication between them, including instantiation of the latter by the former. It might be argued that the user control's presenter is part of the window view implementation, and so the window view may instantiate the user control presenter. But it cannot inject the model classes that the presenter needs, because the view isn't supposed to be aware of them.

The conclusion that I think I am arriving at is that ALL user controls are view-implementation-specific, and so should be contained completely within the view silo of the larger pattern. As such, they don't get to have their own presenters... At least not bundled up with the control implementation itself. Instead they should be manipulated indirectly by the parent window's presenter, via pass-through fields exposed on the view interface. In short, the user control is exposed to the presenter not by its own interface, but rather via a common pass-through interface implemented by its parent view. Call this a "partial view interface".

Your presenter can then contain instances of a re-usable sub-presenter class which works only with this partial view interface, and the relevant pieces of the model. This will allow you to avoid re-writing the presenter code to translate from the model every time you need to use the control, AND it prevents the window view from needing to know about the model in order to pass info through to the control's presenter.

What this effectively does is it further separates the user control, as a module, from your data model. This makes sense if you think of a user control, as a whole, as an element of the view implementation. As a re-usable unit, it is a piece of view functionality, and no part of it should be tied to your data model.