Death to .NET Events

Wednesday, September 30, 2009

When .NET arrived on the scene it promoted the use of events and delegates to decouple code. Chris Sells had one of the best early stories on how it all works (.NET Delegates:A C# Bedtime Story)*:

Once upon a time, in a strange land south of here, there was a worker named Peter. He was a diligent worker who would readily accept requests from his boss. However, his boss was a mean, untrusting man who insisted on steady progress reports. Since Peter did not want his boss standing in his office looking over his shoulder, Peter promised to notify his boss whenever his work progressed.

For a few years I think we were all infatuated with events. We used them everywhere from the web to the desktop, and even in between. Looking around, you have to wonder if we went down the wrong road.

 roadsign

Consider the people who …

I’m thinking one day soon we will compare writing explicit event code to manual memory management.** Both will be low level details we don’t see in our everyday code.

If so, this will be quite a change from just a few years ago.

--

(*) The start of the story should sound familiar to anyone who worked with COM’s IConnectionPoint, which almost qualifies the story for an award in the horror category.

(**) If this means I never see the INotifyPropertyChanged interface in anyone’s code ever again, then I’ll welcome the new event overlords with open arms.


Comments
Chris Patterson Wednesday, September 30, 2009
I had completely forgotten about IConnectionPoint.

Now I'll have bad dreams again.

Thanks!
scott Wednesday, September 30, 2009
You,ll be forever haunted, Chris!
VitaminJeff™ Wednesday, September 30, 2009
HAHA! I remember reading that Chris Sells goodness. :D

Thought provoking post KSA. Thanks. :)
Casper Thursday, October 1, 2009
Dude, have you seen the hoops you have to jump through in the Java world?
wekempf Thursday, October 1, 2009
My first reaction was to consider this an ill informed rant.

1. People dislike the ASP.NET postback model because it's simply a bad fit in the browser, not because it's based on .NET events.

2. Commands are implemented using events, as part of the public API and not as an implementation detail.

3. Aggregator's decouple the source and target, but nearly every single aggregator I've seen uses events, as part of the public API and not as an implementation detail. I've not seen a .NET Pub/Sub design, and would question it if I saw it.

4. LINQ Rx is quite interesting, but it in now way replaces .NET events.

So, I don't see .NET events going anywhere, and think saying "death to .NET events" is silly in the extreme. However, deeper thinking about this, your post is really about the evolution of higher level abstractions, and I can't totally fault that. I still think a lot of what was said was bunk, because these higher level abstractions are not only based on events, but they include the events in the public APIs in one form or another. Maybe, some day, there will be an abstraction that buries them entirely... but that day isn't coming any time soon, IMHO.
Scott Thursday, October 1, 2009
@Casper - Maybe that's a good thing.

@wekempf - On #3 there are a few now. For everything else - yes, this is about higher abstractions, and in some cases using more appropriate abstractions.
Reido Thursday, October 1, 2009
I think to make your point it would have been more effective to explicitly list the specific reasons why and/or specific situations when .Net Events are inappropriate. It seems to me that event-driven code works fine for many simple uses but becomes more burdensome as complexity increases. For instance, if the order of the events is uncertain but the order still matters (i.e. one delegate must assume that a different delegate has already run; once when I writing an Ajax app, I had an Ajax callback that only sometimes needed to execute yet another Ajax call before processing the returned data, and I ended up constructing callbacks within callbacks sorta like continuation-passing style code). Actually, even when the order is set in stone as in the ASP.Net Page Lifecycle, properly chopping up code into event-driven chunks can be a chore to get just right in all possible event sequences.

My favorite replacement of events and/or traditional threads is the high-level concept of an operation queue in which one can set dependencies among queued operations and the queue implementation handles the details.
Dennis Sellinger Thursday, October 1, 2009
Strange as it appears on the surface, I think you are right. The more you work with events the more you begin to understand how hard they are to get right. I am working with a pluggable winforms application and it is true. We would like to limit the use of events because they are so hard to manage when objects that fire them have a limited lifetime.

there are few errors as tricky as event handlers firing on disposed objects.

cheers.
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!