Event Driven ASP.NET Development with C#

Many of today's most popular Web development platforms (PHP, ASP, Perl and Cold Fusion, among others) support Object Oriented Programming (OOP) concepts that help to keep Web application code well organized, modular, and scalable.

But there is another feature of modern programming languages that is less common among Web development platforms: Event Driven Programming (EDP). As one of the few Web development platforms to embrace both OOP and EDP, ASP.NET provides for an unmatched level of developer productivity on complex projects.

In this article, I'll demonstrate the EDP features of ASP.NET and show you how to accomplish a few common Web programming tasks with EDP. While these skills are essential for any ASP.NET developer to learn, Web programmers who have worked with non-EDP platforms will want to pay especially close attention. EDP necessitates a very different approach to some fundamental issues. Habits formed while using other languages can easily translate to inefficient and unnecessarily convoluted ASP.NET code if you're not fully aware of the power of EDP.

This article is the fourth in a series on ASP.NET. If you're new to ASP.NET Web development and haven't read my previous articles, check out Getting Started with ASP.NET, ASP.NET Form Processing Basics, and Object Oriented C# for ASP.NET Developers before proceeding.

Event Driven vs. Procedural Programming

Back in the days before the Graphical User Interface (GUI), most computer programs were written procedurally. A program would be a simple list of instructions (some of which would be conditional upon user input, for which the program would always stop to prompt the user). An icon of popular culture recently summed up procedural programming as follows: "Do this! Do that! Blah, blah, blah!"

The development of the GUI necessitated a more flexible programming model. Gone were the days when every user interaction could be reduced to a simple multiple-choice question or text prompt. GUI-based programs had to be able to react to a wide variety of events, from mouse clicks to background system activity (like a printer running out of paper) without interrupting the flow of whatever task the program was responsible for completing.

Just think -- how smooth would a GIF animation look in a Web browser if, between each frame, the browser had to stop and check if the mouse had moved or been clicked? If any keys had been pressed? If the CD-ROM drive had been opened or closed? More importantly, how manageable would the code for the Web browser be? Enter Event Driven Programming.

These days, you can't write a program for a graphical operating system such as Windows without understanding EDP, but until ASP.NET (and a few other pioneers, such as Macromedia Flash), the benefits of EDP were not available to Web developers.

"Why did all the other languages adopt archaic, procedural programming models?" you may wonder. ASP and PHP developers (myself included!), for instance, have grown accustomed to writing scripts with gigantic if statements of this form:

if (the user did this)
{
 do this
}
else if (the user did this)
{
 do this
}
...
else
{
 do this
}

I can trace the reasoning behind this programming structure back to two sources:

The stateless nature of HTTP

Hypertext Transfer Protocol (HTTP), the protocol used for all communication between Web browsers and Web servers is stateless. Most server-side programming languages (ASP.NET included) support cookies and sessions and other such features designed to overcome this limitation, but when it comes right down to it, each request for a Web page remains a simple ask-and-answer cycle, essentially separate and independent from all others.

CGI and Perl, the Adam and Eve of server-side programming

When server-side programming was first conceived, the Common Gateway Interface (CGI) was the only way to do it. CGI is a standard whereby the Web server will run a specified program, wait for it to terminate, and send back the output of the program to the Web browser in response to its request.

Both HTTP and CGI are exceedingly simple standards that today's Web applications use in incredibly complicated ways. The simplicity of these standards (run a program/script to produce the response for a browser request) suggests a simple programming model; but today's applications demand something more robust.

Rather than a fixed list of instructions to follow, Event Driven Programming lets the developer identify a set of events for which the Web application should watch, and define how to react to each. Developers with a background in JavaScript will think this all sounds just a little too familiar. Indeed, ASP.NET code can look an awful lot like JavaScript code if you tilt your head just so.