Reputation: 55472
Sorry if this has already been asked before but I couldn't find any help.
I was wondering if anyone had any good examples of complex winforms created using the supervising controller MVP pattern. I have read a lot of examples but they are really only simple and only deal with having one form and one model.
What I am looking for is a example that shows how to pass data from one view to another and where the communication lines should be and what should be bound to what.
Say I have UI like this: alt text http://img12.imageshack.us/img12/2683/layoutcroped.jpg
Sorry for the dodgy UI mockup. basically each user control has it own presenter and modal layer object.
What I need to do is take the input of the textbox on user control 1, get the right item from the database using the a service object(in presenter for user control 1) and pass it as the modal to user control 2.
My question is: Do I pass the model to the user control 2 via the view interface or into its presenter?
Sorry if this is a bit hard to understand, I just keep seeing people saying you can use forms with user controls that use MVP pattern but can't find any examples about how to pass around data between the two.
EDIT: I have draw up two different was I think I could do this:
and
I think Ex1 is the better one as it still leaves the presenters in charge. To do what they want.
What do you think?
Thanks.
Upvotes: 3
Views: 3554
Reputation: 49978
Supervising Controller is used if using a state-full Model and we need the Views to immediately synchronize with it through the observer/observable mechanism, in this case we might be wiling to cut down on testability and allow direct communication between the View and the Model.
Notice that the View is prompted to update its display by both Presenter (directly) and Model (via event). In most cases the view responds to simple changes in Model state and update itself, when more complex logic is involved -the Presenter takes the responsibility to change the View according to application rules.
So for you example, your UserControl1 would send the data to the model through the presenter, and the model would then notify all registered views of the change (send them to model to update accordingly).
Hope that helps.
Upvotes: 1
Reputation: 847
The way I would approach this is from an event oriented, publish/subscribe approach.
The pattern goes something like this:
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.
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.
Upvotes: 1
Reputation:
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.
Upvotes: 0
Reputation: 12833
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
Upvotes: 0