Professional Cairngorm™

21.3. How Events, Commands, and Delegates Have Been Used

Events, commands, and delegates have been used in more or less the suggested way. Each event class had a corresponding command class and, when the backend needed to be accessed, a corresponding delegate.

Event classes that needed to pass data did so by referencing value objects in public properties (with the exception of the KeyWordSearchEvent, for reasons we explained when you created the class). Because of this, those properties were available to the command classes via a reference to the dispatching event.

Command classes would take in the data from the event and use it to either update the model (e.g., SetCurrentPostCommand) or pass the data along to a function of a delegate class.

Delegate classes provided functions to access the backend. In most applications this would be a server call using one of the remoting classes such as the HTTPService. In the sample application, delegates instead called functions on the FlexBlogDatabaseManager. These functions passed back data to the calling command class using the result object of the ResultEvent or calling the fault function if something went wrong. In a typical application using something like HTTPService, this is all taken care of for you via the IResponder interface. Regardless, the basic idea remains the same: delegates serve as a proxy for interacting with the backend.

The one-to-one correspondence between these classes has the benefit of making it easy to track down ...