0

I've got an WinForms application that uses MVP and I'm not entirely sure how to approach the scenario of when I need to create new UI elements.

For the sake of example, let's say my view has a button which is supposed to open a new view (Form) as a dialog. Is the view or the presenter supposed to create the new view or is it the job of the presenter?

This is my thought process:

  1. The view should create it as it as a UI specific operation. But...
  2. The presenter should do it because the view is just supposed to be passive. But the presenter shouldn't know the specifics of the UI.

Which is the correct way to approach this?

Ant P
  • 24,820
  • 5
  • 68
  • 105
Jake
  • 1,701
  • 3
  • 23
  • 44
  • Well, it really depends. If you can generalize creating views, then it might be the P scope. If such views do not have influence on business logic, then views might create such views themselves not requiring a presenter to interact with them. Let's say, if you have a simple Google Maps-driven application, your Google Map instance _may_ create internal views that could interact with the _main_ presenter not even letting it know that a sub-view is interacting with the presenter. I'd go for the 1st one by default, because the 2nd approach makes the P<->V interaction more complex. – Lyubomyr Shaydariv Jul 01 '16 at 14:29
  • None of the views have influence on the business logic as far as I know (for now anyway). My understanding of MVP is anything to do with the UI should be done in the view and the presenter only needs to be concerned with the manipulating the view and model properties but shouldn't be creating UI elements. – Jake Jul 01 '16 at 14:40

1 Answers1

1

I've seen this done a couple different ways. It's funny how all the patterns seem perfect on paper and then implementation details show how it's not that simple. I'm going to give examples as a MVW (model-view-whatever) because it should be similar in any pattern.

Option 1: Bind to a property. This is a little more difficult with WinForms but works great with WPF. Have your button set a bool property on your presenter/controller/viewmodel. Your view then simply shows or hides it's UI based on this value. The UI can overlay all existing UI to have the appearance of a modal.

Option 2: Services. Introduce a DialogService (hopefully you have dependency injection set up so it's trivial to add). This service has a method of ShowDialog(options). Options could be title, message, commands (with titles and actions for button). Have your button set a property or fire a command on your presenter that then calls it's dialogService's ShowDialog method. This way your view is still just simply calling your presenter and it is using the service. Views shouldn't know about services. This allows your DialogSevice to construct the appropriate UI and then launch the new form. This is also how I like to wrap up the native MessageBox.Show calls so you can replace all these with a DialogService.

Option 3: Don't be a purist. If your modal doesn't need to interact with a presenter or you simply want basic data back (say a color picker or something like that) then just let your view take care of it. Your button can simply open the modal, the modal has values that are sent back to the view. Then your view uses them. If the data has no reason to make it back to a presenter, don't over complicate things to be a purist. Views can still perform UI based logic. I use the view for many UI only things such as moving elements around with mouse/touch events or pinch to zoom calculations. If logic is UI only, keep it in the view's code behind. If it's repeated UI logic move it to a service or user control or custom view.

In all the MVP/MVC/MVVM docs, they are always missing crucial details. To me, Services is the missing link. They allow loosely coupled logic to be plugged in and you can wrap up some of the ugly UI bindings or UI events into services and keep things tidy.

Hope this helps.

ManOVision
  • 1,853
  • 1
  • 12
  • 14