Well, OK ... but that's the part I don't get ... I just don't see how you would do this with events on the presenter class. It seems to me, that in this particular case, it's user-driven (or at least UI-driven) stuff. Am I missing something?

~~Bonnie




>Ok, if you look at this example:
>
>http://blog.vuscode.com/malovicn/archive/2006/10/10/Model-View-Presenter-_2800_MVP_2900_-pattern.aspx
>
>Using MVP, I am referring to only this section of code:
>

>private void searchButton_Click(object sender, System.EventArgs e)
>
>        {
>
>            _presenter.SetCustomerData();
>
>        }
>

>Instead of calling the presenter SetCustomerDate() method directly in the searchButton_Click, it could be event-driven. Now, I used a button click as an example, but it could be anytime you need to call a method in the present...
>
>MSFT's example shows calling the method directly (as do most examples on the web):
>
>http://msdn.microsoft.com/en-us/library/cc304865.aspx
>
>
>>Tracy -- In this particular case, your UI is already raising an event ... the button click. Wouldn't your button click event handler simply call the method in your controller class?
>>
>>Evan -- you mentioned that you use the MVC pattern also and it's all event-driven. Could you explain how you'd have an event in the controller class that the UI responds to? (or maybe I misunderstood what you wrote) I would think, as Viv said as well, that it would be the other way around (as I mentioned above).
>>
>>~~Bonnie
>>
>>
>>
>>>Let's say you have a button on a form. When the user clicks the button you want to execute a method in another assembly, say the presentation layer. It is possible that the method may or may not return a value in which the control on the form will take a specific action based on the return value. At other times, no value will be returned. Another example would be validating the value entered in a textbox. Perhaps you want to run validation code in the presentation layer and proceed based on what the code in the presentation layer determines should occur.
>>>
>>>What is the benefit of calling the method directly?
>>>
>>>What is the benefit of raising an event to run the code?
>>>
>>>Is there any time when you would not want to use the 1st or the 2nd?
>>>
>>>Is there a standard practice as to when both would be preferable to the other? I am pondering this in regards to the MVC (model view controller) design pattern if it makes any difference. Mostly just in general though. The method or event will never be in the form UI but rather in the presentation layer (that is why the MVC).
>>>
>>>I'm hoping on starting a general discussion. I've been reading up on some of the benefits to event-driven (e.g. multi-threading) and yet there are times when calling a method would be much simpler and faster to code. I can easily get it working both ways. There are times when it would be beneficial to force a wait for the return from the method (halt processing until the method finishes firing) and other times when you would want control to return immediately while the event processes in the background (expensive processing). There is also the issue of tracing through the code. It is easy to trace when then the method is called directly, but events are much more difficult.