Tracy,

Everything new I'm developing is now completely event-driven rather than direct-method-call driven, regardless of the layer. It's improved my productivity several-fold.

Benefits: you can develop the presentation layer without concern for the business or data layers (or others, for that matter); it's much easier to follow the MVC pattern; it's a breeze to develop stand-alone monitoring tools for your layers and/or components; loose coupling keeps the pieces-parts a lot simpler and quicker to develop/maintain; if you use MVC, multiple presentation layers to the same logic/data become a lot simpler to manage.

Drawbacks: harder to debug (unless you're doing TDD on all the modules); you end up writing a *ton* of test stubs, which are a pain to manage (and remembering their names at my advanced age is also a problem -bg-); if you're not careful, same-layer validations can quickly become tightly coupled or circular; explaining your approach to other developers not at your skill level is a HUGE minefield; if you're developing a small app, it may be overkill.

Just my USD$0.02...


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