Generics are a Common Language Runtime feature that language compilers and the .NET Framework fully support. What about ASP.NET? What is, if any, the intersection between ASP.NET and generics? Like in many other .NET programming contexts, generics can be used in ASP.NET to write neater and more strongly typed code. However, the vast majority of sample code for ASP.NET 2.0 doesn’t use generics. Why is it so? I don’t have the definitive answer, but I can make some guesses. First and foremost, ASP.NET 2.0 was not designed with generics in mind. Just because they are such a powerful feature, to take real advantage of generics, you need to design the code in a much more parametric way. This is true for developers authoring pages and controls, but it was even more so for the Microsoft developers who actually wrote the ASP.NET framework. I’d even say that ASP.NET supports generics, but it doesn’t seem to be conscious of this new and exciting possibility—not in Version 2.0, at least.
However, there are few things that you can do in ASP.NET today that involve generics. Let’s briefly tour through them. They are: event handlers, collections and data binding, and viewstate.
In ASP.NET 1.x, to define an event on a custom control, you had to define a delegate and an event data structure. For example, to fire the event ViewCollapsing and pass some control-specific data, you need a custom delegate like:
delegate void ViewCollapsingEventHandler(<br> object sender, ViewCollapsingEventArgs e);
In addition to defining the custom event-args class, you need an explicit declaration of the delegate. Next, you define your event:
public event ViewCollapsingEventHandler ViewCollapsing;
The point is, all event delegates share a similar structure. They are void and accept two arguments, the first of which is the sender (an object). The second argument varies and corresponds to the event-args class. If you look at it with a generics-open mind, you can’t help but note the similarity. What is the event-args class if not a parametric type?
In light of this, in ASP.NET 2.0 the EventHandler class—the default class for event handlers—also sports a generic version: EventHandler<T>. If you use this version, you can declare events on pages and controls without explicitly defining the event handler delegate. Here’s how:
public event EventHandler<ViewCollapsingEventArgs> ViewCollapsing;
You define the event-args class and go. No other code is required.
Another scenario in which generics are transparently used is the viewstate storage. You can work with generic collections and still save and restore them from the viewstate.
public List<int> MyIntList<br>{<br> get <br> {<br> object o = ViewState["MyIntList"];<br> if (o == null)<br> return new List<int>();<br> return (List<int>) o; <br> }<br> set { ViewState["MyIntList"] = value; }<br>}
The same holds true for data binding. All data-bound controls don’t distinguish classic collections from generic collections.
Finally, ASP.NET accepts custom controls with a generic declaration; for example, a custom control where one of the properties owes its runtime type to the generics layer.
public class GenControl<T> : WebControl<br>{<br> public T Data<br> {<br> get { return (T) ViewState["Data"]; }<br> set { ViewState["Data"] = value; }<br> }<br> :<br>}
If you create instances of this control dynamically, all works just fine.
GenControl<int> x = new GenControl<int>();<br>x.Data = 3;<br>Controls.Add(x);
Unfortunately, you can’t work with these controls from within Visual Studio 2005.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant
based in Rome, Italy. Dino is a contributing editor to Windows Developer
Network and MSDN Magazine, and the author of several books for Microsoft
Press including Building Web Solutions with ASP.NET and ADO.NET
and Applied XML Programming for .NET. Contact Dino at [email protected].
