Ensure User Control Reusability
User controls are a useful way to reuse code, but only if you design them well.
by Jonathan Goodyear, MCSD, MCP, CLS

VSLive! Orlando, September 17, 2002

Note: Jonathan Goodyear is presenting "Templates and Code Reuse in ASP.NET" at ASP Live! Orlando, Tuesday, September 17. These tips are from that session.

ASP.NET exposes two main methods for packaging user interface elements to produce reusable code in your Web applications (see Resources). Custom server controls are fantastic for generation of complex or templated UI elements, but sometimes you just want to aggregate some controls in a logical grouping that you can reuse. That is where user controls shine. Unfortunately, if you don't design your user controls well, they lose many of their reusability benefits. Here are a few tips to help you design highly reusable user controls.

Keep the User Interface Simple
The more complexity you add to your user control, the harder it will be to reuse later. Keep in mind that a user control doesn't have to be large. It can be as simple as a TextBox with a Label that serves a particular purpose. If you find that the user control you are designing performs more than one distinct function, split it up into pieces. The best approach is to build your ASP.NET pages using a larger number of compact and reusable user controls, rather than one or two über-user controls.

Avoid Hard-Coding
Hard-coding scenario-specific parameters can kill the reusability of your user controls. Leave as many options open to customization as possible. User control properties are a great way to accomplish this. For instance, if you were building an e-mail user control, some of the properties you'd want to expose would be destination e-mail, subject, mail server, and default body text. Be sure to include defaults, however, so that your user control can easily be used in its most basic form. If your user control requires setting dozens of properties to be used, it's much less appealing to developers.

Keep Them Self-Contained
It is important that you design your user controls to be atomic in nature. Don't rely on the presence of other page elements for your user control to operate properly. For instance, it is not a good idea to open an HTML table in one user control and close that same HTML table in another user control. This sounds like common sense, but those of us with a traditional ASP background often used server-side includes to do just that for ASP page headers and footers. User controls are not server-side includes, and should not be treated that way. Following that same line of thought, do not attempt to directly manipulate anything outside your user control's scope, even though technically you can accomplish this by accessing its Parent property. This can lead to disaster if the control you are attempting to manipulate does not exist, or is not where your user control expects it to be. If you need to communicate with other user controls on your ASP.NET page, publish .NET events that other user controls can subscribe to (see Resources). This is a more decoupled and fault-tolerant approach.

Accept UI Parameters
User controls should be employed to encapsulate functionality, not look and feel. If your user control contains highly customized user interface elements (such as fonts, colors, and images), then its reusability will be severely hampered. As an alternative, expose properties in your user control that allow its UI to be customized. Also, avoid using hard-coded CSS style classes that refer to external stylesheets. The formatting of your user control will be ruined if the stylesheet is changed or removed from your Web application.

User controls are easy to build, but don't let their simplicity prevent you from designing them carefully. As with server-side includes in traditional ASP, user controls can quickly turn your Web application into an absolute mess if they are not designed and implemented properly.

About the Author
Jonathan Goodyear is the president of ASPSoft, an Internet consulting firm based in Orlando, Fla. He is a Microsoft Certified Solution Developer and is the author of Debugging ASP.NET, published by New Riders Publishing. Reach him by e-mail at jon@aspsoft.com or through his angryCoder eZine at www.angryCoder.com.