How often do you use custom events?

Question

I've been learning some new features of ASP.NET beyond my current level of comfort, and I'm trying to figure out exactly how custom events can fit in, from a design standpoint. I know how they work, and the observer/subscriber pattern, but it seems that custom events aren't talked about much. It seems like an entire app could be built from registering events and responses all over the place, and yet, we see more controller-type classes that fire bits of code off in a predetermined pattern...it's OOP, and yet still sort of procedural.

So speaking from a design standpoint, when is it best to use events? Are there certain scenarios that they are very handy for, but not much else? Or is it possible to create an app that relies heavily on them, and a programmer can use them as much or as little as they want?

Mostly I'm just curious as to where they fall into "proper" design, as I can easily re-imagine an app or two of mine leaning on them much more as opposed to just firing off controller class logic when a button is clicked.

Answer 1

Mostly I use custom events when building custom controls.

In ASP.Net I don't use custom events much at all, since even with the custom controls I try to rely more on the existing page life-cycle.

In Windows forms almost everything I do is abstracted into a control somewhere, and so I use them quite a bit.

Answer 2

I've done a lot of custom events in ActionScript 3.0. I mention this because its delegate system is fairly similar to .NET.

I was creating an SWF player that could queue up multiple clips at a time. My custom Timeline control would fire ClipEnd events, which my main application would listen for and advance the Playlist. My Playlist would fire NewClip events if either the user advanced to a new clip, or the app automatically did. My app would listen for these and tell the Timeline to start playing the next clip. So my Timeline and Playlist were symbiotically linked via custom events.

Answer 3

You don't see as many custom events in asp.net code mostly because the things that can trigger an "event" tend to be things the user did on the client via one of the built-in controls like a button or what-not. The server itself doesn't really "interact" with the code as it executes in an event-driven way though.

One you get a postback goind via one of the regular controls. The execution on the server tends to be very procedural in nature... that is just the pattern that makes the most sense in a stateless request/response environment like the web.

The asp.net page life-cycle and server controls all have lots of events they expose and may fire those OO like aspects are really just supporting what is by its very nature a highly procedural and linear execution path.

Custom Server controls expose custom events just like the built-in controls do so that page developers have a mechanism by which they can interact with the control without tight coupling... so that is where you'll find most custom events. But the cost of making a custom server control is really only worth it if you really do have a lot of different pages where the control might be used.

I often use events in user controls too. while you can treat a user control very similarly to a server control, generally user controls tend to be weak in terms of OO design principals. With user controls, you are usually just trying to gain a little bit of a separation of concern and some encapsulation, but you'll tend to still have a fairly tight coupling between the hosting page and the user control. but still, sometimes a user control may need to signal to the hosting page that some condition has been met, and in those cases a custom event is a good way to handle that signaling with less coupling than directly calling a method on the hosting page.