6

I have a WinForm and few properties that are set on it.
for example : Name,Address are accepted on the Form.
(many more properties in actual example)

The current implementation is somewhat similar to 

frmName frmView = new  frmName (); //frmName  is WINFORM 
frmView.Name= "ABC"; //any valid string or read this from file
frmView.Address="SomeAddress"; //any valid address or read this from file

if (frmView.ShowDialog() == DialogResult.OK)
{
    //OK CLICK PROCESS and
    // get new values edited by user
     string name = frmView .Name;
     string address = frmView.Address;
     doProcessing(name,address);
}
else{
  //Ignore cancel click..
}

how do i convert this to a MVP based Winform application.
Also need to refactor the processing done on ShowDialog() to the Presenter/Model
(dunno exactly where to do it)?
Also need to avoid writing code on the form itself.(Passive view)

Thanks All.

Amitd
  • 4,769
  • 8
  • 56
  • 82

1 Answers1

7

I'm still experimenting with different MVP approaches myself, but the way I'm currently doing it is like so:

frmName frmView = new frmName();

if (frmView.ShowDialog() == DialogResult.OK) {
    presenter.RequestProcessing(frmView.Name, frmView.Address);
} else {
    //Ignore cancel click..
}

You say you want to avoid writing any code on the form itself, but this doesn't make sense to me. In Passive View, you pass on all application-specific requests to the controller or presenter.

In this example, the view handles view-related logic. Opening the dialog box isn't a user action that anything else (such as the presenter) needs to be informed about. Just like opening a context menu, a dialog box is part of how this particular view chooses to offer those application-specific requests to the user. Until the user actually goes through with it and submits the request, the presenter doesn't need to know anything.

In some circumstances where I've needed to be able to handle errors within the dialog box itself, I've passed the IPresenter object into the dialog box's constructor. It can then make the appropriate presenter request itself when the "OK" button is clicked, for example, and can show a message box instead of closing in case of an error.

There are a lot of variations on MVP, but I hope this helps. Good luck with setting it up.

Rich
  • 3,081
  • 1
  • 22
  • 24
  • thx for answer. Also please can you explain the handling of errors part.. (3rd paragraph.. "In some circumstances where ....") – Amitd Aug 09 '10 at 11:41
  • @Amitd: In the code example in my answer, the user request is forwarded to the presenter upon *closing* the dialog box. What if that request results in an error? For example, that same name and address has already been processed and saved somewhere. It looks better to display the error from within the dialog box and allow the user to change their name or address, instead of having to open a *new* dialog box to try again. You can do this by passing the presenter into the dialog box, having it make the request itself, and only closing it if it *does not* result in an error. – Rich Aug 09 '10 at 11:55
  • @Rich : Oh ok. So I will need to keep the presenter as a property of the view instead of creating new presenter inside the view ? – Amitd Aug 09 '10 at 12:51
  • @Amitd: It's up to you how you choose to handle the creation of the presenter. You can either do it from inside the view, or create it from outside (perhaps in your main method) and pass it into the constructor. Either way, the view will need a private reference to it so that it can interact with it. – Rich Aug 09 '10 at 13:05
  • @Rich : thanks. i did it the 2nd way..passing the Presenter thr constructor. (IPresenter was gr8 idea ..much more flexible.) – Amitd Aug 11 '10 at 11:32
  • @Amitd: Yes, using interfaces here are very useful. It allows you to change out the presenter implementation entirely, and helps if you plan to do any testing. I'd appreciate it if you could mark this as the best answer, if it was helpful to you. :) – Rich Aug 11 '10 at 23:06