Question

In doing a lot of ASP.NET pages (.NET 2.0), my codebehind is typically packed with event handlers on page objects. GridView_RowCommand, Button_Click, etc. All the usual suspects. One thing all EventHandler derived things have in common is that their first argument is an object, typically labeled “sender”.

In ASP.NET codebehind, I really don’t see the point of it. If I have GridCustomers_RowCommand and I need to do something to GridCustomers, I can just access it from the codebehind instead of worrying about casting sender to a gridview and then working with it.

I feel like I must be missing a very important design consideration here. Am I doing something stinky to my code? I kind of can see that using direct references this way is falling prey to global objects, but that’s just how ASP.NET works! What am I not seeing here? Is there some superb book or tutorial that shows how to use ASP.NET the “right way?” The clean, agile, “real coder” way?

Answer 1

You might have one event handler for DRY coding, yet 20 things that use that event, for example:

protected void AddClass(object sender, EventArgs e) {
   ((WebControl)sender).CssClass += " myNewClass";
}

In this case you’re writing the code once, but it can be used by many WebControls (this is an example, the point is not specific to WebControls at all).

Disclaimer: Do I use sender every day? no not even close, is it useful? yes it can be 🙂