Hi Tracy,

I'm don't think events would be the way to go here. If you're looking at classic n-tier design it would require your middle layer (that handles the event) to have knowledge of the UI layer. Conversely, from the UI POV, if you expose a public event then you have no knowledge (or control over) what other processes may consume the event. Seems to me events are usually implemented in the other direction (i.e. used to notify the UI that something has happened in middle layers)

Just my 0.02c,
Best,
Viv

>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.