Hi Tracy,

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

Just for discussion purposes and speaking to the specific case you mentioned. If you raised an event for validation that may or may not return a value; how would you know when it is OK in your form to allow them to save? I suspect this is one of those cases, depending on the logic involved and interaction with entereing data in other controls that you would want to have absolute control ( a method; tightly coupled) to validate either upon leaving the control or when clicking a save button.

On the other hand, I like using events paticuraly in cases where the object doesn't know anything about the listener. For instance in my business layer or in components where they don't know anything about the presentation layer or if anybody is listening. Raising an event there allows the component to be consistent and the listener to decide when it wants to respond, how, and maybe not at all (loosley coupled).
Tim