Solution Architecture

The .NET Framework standardizes the callback process by using the same commonality of implementation that permeates its other parts. Events are first-class members of the programming and runtime environment. An event is a named occurrence that a sender thinks a listener might want to know about and react to—for example, the completion of an I/O operation or a human user clicking a button. The act of notifying listeners that the named occurrence has taken place is called firing, signaling, or sometimes raising the event.

An event is a named occurrence that a sender thinks a listener might want to know about.

A programmer who wants to write code that fires an event declares the event by using a source code keyword and specifying the name of the event and the type of handler that a listener must provide to be notified of it. A listener that wants to be notified of the event must provide the sender with a handler, known as a delegate, of the specified type. This process is shown in Figure 8-1. A delegate is a .NET object, of class System.Delegate or its derivatives, that wraps the address (pointer, to you C++ geeks) of a callback function (which I call the target function) that is implemented in the listener. The target function can be either a class static (shared in Visual Basic) function or, more commonly, a method on an individual object. It contains the code that the listener wants to execute when the sender fires the event. The delegate object contains methods that the sender can use to invoke the target function. When the sender wants to fire the event to the listener, it uses the delegate’s invocation method to call the target function, as shown in Figure 8-2. Don’t worry if it sounds like a lot of work; your language compiler does most of it for you, as you’ll see. I discuss events, first simply and then in more complexity, in the first two examples in this chapter.

A sender fires an event to a listener by making calls on a delegate, a callback object provided by the listener.

Figure 8-1: A listener providing a sender with a callback object (delegate).

Figure 8-2: A sender calling delegates to fire events to a listener.

To support run-time and design-time discovery of its capabilities, each sender object contains .NET metadata describing the types of events that it fires. This information allows intelligent development environments to provide various types of user interface support, such as IntelliSense and wizards, that make it much easier for programmers to use events.

A .NET object contains metadata specifying the types of events it fires.

Although events are by far the most common use of delegates, you know there’s no way programmers would leave such a useful and generic mechanism alone. Delegates are employed as generic .NET function pointers even when not part of a named event. For example, a client can use a delegate’s asynchronous invocation capability to call any function asynchronously. I discuss the generic use of delegates in the third example in this chapter.

Delegates are also useful as generic callback objects.