Example: Getting Data Back From An EventHandler

Background

I previously wrote about why I like to use events here and here. I figured it would be appropriate to illustrate a simple case where you can delegate decisions between functionally separate parts of code (say, between an application layer and a presentation layer). If you're well versed in C# and .NET, this might put you to sleep. If you have no idea what I'm talking about, hopefully this will help. By the end of this, hopefully you'll have a better idea for how you can use an EventHandler to pass data/state back through an invoked event... And don't forget to check out the code!

The Scenario

Let's assume we have a layered application, which is usually my go to. I might have three layers: one for data persistence, one for my business logic and one for interacting with the user. I'll call these the data, application, and presentation layers, respectively. Let's also assume that the dependency flow works from the top layer down (so presentation layer depends on application and data, and application depends on data). Nice.

In my application layer, I have a class that can process data. Specifically, it can capitalize an input string and spit out the capitalized output. However, some input characters are not letters A-Z or a-z... So how should our processor behave? Let's have it delegate this decision to the user (who interacts with the presentation layer) and get back our result.

The Workflow

The following is the workflow for the application:

• Create a processor object
• Hook on the event handler so that the presentation layer can handle the corresponding event
• Start processing the input
• Capitalize valid characters
• When we reach an invalid character...
  • Call our data processor's event to delegate the work to anyone who can make the decision for us (in this case, our presentation layer)
  • Have the event handler (the presentation layer) ask the user if we should skip the input
  • Store the result back on the event args
  • Back in the processor class, based on the result of the event args, we can skip or add the character.

  ## Summary It's a pretty straight forward task really. Because these event args are reference-type objects, the handler can mutate the same instance the processor reads afterwards; assigning a new object to the handler's local parameter would not replace the processor's reference. A value type passed by value would instead be copied, so ordinary property mutations would not return the decision; returning a value or using a custom delegate with ref/out parameters are alternatives. In my opinion, this is a bit uglier (but certainly still doable).

This decision flow requires synchronous handlers: an async void handler may return before setting the decision. Define the default when nobody subscribes and the precedence when multiple handlers disagree; a single callback returning a decision can make single-owner request/response clearer, while mutable event args preserve the familiar event convention.

I've created a sample project and hosted it at Google Code, here. Check it out!