locked
MVP Pattern, Who drives the Views RRS feed

  • Question

  •  

    Hi all,

     

    I'm new to this Model View Presenter pattern and like the idea allot. However I'm running into problems when I do anything more complex that using an application with a single form. This is a WinForms application, at the moment.

     

    My question is who drives the view. What I mean by this is; lets say you have a Windows Form with a Button, which when clicked shows you an Options Dialog for that Form.

     

    My idea is that I pass the button's click event along to the Presenter as say a ShowOptionDialog event. It's then the Presenter job to create the new Presenter for the new Dialog View. Since the new Presenter knows which type of View Interface the new dialog is coupled to, the Presenter would then request to the View that it wants a View of say type IOptionsView via a CreateView function on the parent views interface. It's then up to the View to create the correct Form that implements the requested Interface. When the View has been created, it's IOptionsView interface is passed back to the presenter and the presenter then hooks the IOptionsView interface to the new presenter and on we go.

     

    This way it's the presenter that's in charge of application flow, not the view. Also this makes the view even dummer, since it's one less decision the view has to make + the presenter can be tested even more.

     

    Another example would be of say a wizard style view where the sub views need to be shown in a particular order. Do you really want the view to decide this order?

     

    With all of the the MVP examples out there that show more than one view (there aren't many), it's the view's job to create the presenter and attach itself to the view, which means the view is essentially driving the application.

     

    Does this sound like a good approach or should the Views always dictate which view/presenter should be shown due to some user interaction.

     

    Any thoughts, welcomed

     

    Regards

    Neal

    Saturday, December 8, 2007 11:27 AM

Answers

  • Neal,

     

    One of the reasons most of the examples show the view creating the presenter is that they're in a web environment where the runtime (ASP.NET) handles the creation of the views automatically.

     

    For WinForms/smart clients I prefer to use the supervising controller (SC) pattern where the view exposes business level methods and events, as opposed to button_click etc. ShowOptionDialog is OK, but I think that an event called OptionsRequested would be more explicit - should the original view know that options are presented on a dialog?

     

    Personally, I don't have a problem with one SC opening/managing more than one view - if it's a modal view or things like a search form for the same kind of entity as already being managed by that SC. I view SC as being more about managing things dealing with a specific kind of entity, rather than being focused on the view. I've found that that leads to a good DDD-style of separation. I try to avoid having one SC know about other SC's. Each SC communicates with the rest of the system using commands, or by updating an entity, which eventually calls back into another SC.

     

    Hope that helps.

     

    By the way, if you're developing a multi-threaded smart client, there are several other things to be aware of. I've written about the Controller-View interaction and why AOP helps a lot here:

     

    http://udidahan.weblogs.us/2007/12/07/eureka-aop-is-the-final-piece-of-the-multi-threaded-smart-client-puzzle/

     

    Saturday, December 8, 2007 4:31 PM

All replies

  • Neal,

     

    One of the reasons most of the examples show the view creating the presenter is that they're in a web environment where the runtime (ASP.NET) handles the creation of the views automatically.

     

    For WinForms/smart clients I prefer to use the supervising controller (SC) pattern where the view exposes business level methods and events, as opposed to button_click etc. ShowOptionDialog is OK, but I think that an event called OptionsRequested would be more explicit - should the original view know that options are presented on a dialog?

     

    Personally, I don't have a problem with one SC opening/managing more than one view - if it's a modal view or things like a search form for the same kind of entity as already being managed by that SC. I view SC as being more about managing things dealing with a specific kind of entity, rather than being focused on the view. I've found that that leads to a good DDD-style of separation. I try to avoid having one SC know about other SC's. Each SC communicates with the rest of the system using commands, or by updating an entity, which eventually calls back into another SC.

     

    Hope that helps.

     

    By the way, if you're developing a multi-threaded smart client, there are several other things to be aware of. I've written about the Controller-View interaction and why AOP helps a lot here:

     

    http://udidahan.weblogs.us/2007/12/07/eureka-aop-is-the-final-piece-of-the-multi-threaded-smart-client-puzzle/

     

    Saturday, December 8, 2007 4:31 PM
  • Udi,

     

    Thanks, that has given me some more things to think about. I'm going to have to bite the bullet and learn some asp and build a few WinForms & asp views at the side by side at same time.

     

    I think I'm trying to couple different views & presenters together too tightly. You asked should the original view know that options are presented on a dialog? I guess the answers no, hence OptionsRequested is a better name for the event (if I even need the event now). I'm also thinking that there is no real need for the presenter to rigidly request the type of view it needs. I just need a little more trust that the view will create the correct child dialogs/pages or sub views without the parent presenter strictly enforcing it.

     

    Many Thanks

    Neal

    Saturday, December 8, 2007 11:02 PM
  • I have some of the same issues. I like the idea of the Main presenter requesting new views from the "Main" view. The problem I have, is if the view is going to display the new view (i.e. form), how do you deal with when the view is going to be a dialog box? Does the view have to have a "Show()" method in the interface? What triggers calling form.ShowDialog? If it's the view, and the view calls show dialog when the new view is requested by the presenter, the call doesn't return until the view is closed.
    Wednesday, August 12, 2009 3:07 AM