Complex Supervising Controller examples for winforms

Answer 1

I think from what your saying that you'd be best off thinking in terms of having one presenter dedicated coordinating (and supervising) what is needed to a specific presentation (ie, "Gather Customer Information"). Then think of passing the model (or a facade of it if there is sufficient complexity) into that Presenter on construction.

If the user control has a presenter that is itself tightly coupled to the model (a text box doesn't on the surface sound like it would be) then you can pass that model into that presenter, but I would not pass it into the view interface.

I'd need to know a bit more about what you're calling user controls right now to have a chance at helping you architect a presentation of them.

I don't know of one example that would nail the scenario you're starting to flesh out, but I would focus on the different mvp examples on Fowler's site, and look at Jeremy Miller's Build Your Own Cab series. Both will be a bit frustrating as neither will quickly solve your issues, but both will lend insight into facets of this broad topic.

Hope It Helps! Berryl

Answer 2

Hi

We had some serious issues with this subject. We at first assumed that first view is responsible for creating and configuring second view and first presenter for crating and configuring second. This solution was bad for many reasons. First of all second view was configured by two other objects (first view and second presenter). Second drawback was binding views together and having logical responsibility on view.

We were looking for solution for some time and decided that we need this binding to be loose and executed in presenter. So we created factory crating pair of view and presenter which is matched to given id (string or guid). When user executes some action on view this call is forwarded to presenter and there is made decision which pair should be displayed.

Answer 3

The way I would approach this is from an event oriented, publish/subscribe approach.

The pattern goes something like this:

1. The user clicking the Edit button on the first view fires off an event (you could call it a command) with a single parameter (the ID, value of the textbox in this case). Call the event "EditRequested", say. This is the "publish" of the event, telling anyone who wants to know that this has occurred and the details. The actual publish might be done in the controller/presenter.

2. The controller/presenter for the second view listens for the above event and, when the event fires, acts accordingly, loading the data and switching to edit mode using the event parameter (ID). This is the "subscribe" part of the pattern.

Ideally this would be done using an event aggregator (CAB provides one as does Prism) but you can probably do something manually for a single case. The event aggregator removes the need for the publisher and subscriber having to be aware of each other, improving loose coupling.