Death to .NET Events

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.

Consider the people who …

• like ASP.NET MVC because it doesn’t have a postback event model
• transform events into commands
• layer over events with an aggregator, or avoid “events” altogether using messages and PubSub 
• treat events like streams 

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.