Many ASP.NET developers use Web controls, but few have taken the time to explore how to develop their own custom Web controls, thereby potentially missing some very useful, reusable functionality.
by Miguel A. Castro
Nov 2, 2005
Page 2 of 6
Advantages of Using Web Controls
Programming with custom Web controls provides several advantages in all stages of development, among which are:
Isolation of Visual Components. Web controls allow you to group related visual components together into a single component and encapsulate all functionality and visual representation associated with that component within the Web control. This is especially true in the case of Composite Web controls, but more on that later.
Reusability, Reusability, Reusability. Writing custom Web controls for your applications will provide you with the ultimate method of reusability in Web development. Web controls compile to an assembly, just like any other Web component; so you can reuse them on any page of any Web application you want, depending, of course, on the desired intention of the specific Web control.
Cross-Browser Compatibility. In the old days, developers performed browser-checks on a Web page, whether it was in ASP script code or client-side Jscript. Using the results of this browser check, you could decide how to render different HTML for the appropriate browser your application was being accessed from. When you develop a custom Web control, you can perform your browser checks within the control's code itself; letting the Web control decide how it should properly render itself.
Self-Maintaining State. Web controls can, and usually do, control their own state in order to persist information they need during page postbacks.
Full Object-Orientation. As I mentioned before, Web controls are just classes, albeit pretty elaborate ones. This means they can inherit, be inherited, implement interfaces, and take part in any design pattern you see appropriate to use.
Declarative Programming. Web controls allow you to program declaratively. This means they let you separate the "What to do" from the "How it is done" on your Web Forms. They help you eliminate clutter on your Web Forms by removing code and placing it with the Web controls, making the code on your Web Form much easier to follow. I'll talk a little more about this at the end of the article but if you want more detail on Declarative Programming, check out my article titled, "ASP.NET Development Through Web Controls and Declarative Programming" in the March/April 2005 issue of CoDe Magazine. Like it or not, things are moving more and more toward Declarative Programming with the coming of XAML in the near future.
Did I Mention Reusability? I can't stress enough, the level of reusability that custom Web controls bring to the world of Web development.
Types of Web Controls
There are three types of Web controls, each with their own characteristics and advantages. When to use one or another is a topic of discussion on several forums. The problem is that some discussions seem to favor one type while other forums favor another, and both for the same type of use. I am going to explain each type and also give you my own opinion, coming from my experience, as to when each type is useful.
Inherited controls consist of a class that inherits from an existing Web control class, usually one of the ones provided by Visual Studio. You usually use this type of custom Web control when you simply need to extend an already existing control with some extra functionality. For example, you might have a dropdown box that pre-fills itself with information. Say you anticipate many places within a site (or multiple sites for that matter) where you need the ability to select a US state. There's no need to use a standard dropdown control and then fill each one in each of the page's code-behind class. Simply write a class that inherits from the existing dropdown control class, add the functionality to fill itself with US states, and that's it. Dropping that control on a Web Form will automatically render it with the US states pre-filled.
As another example, consider a textbox with some added properties. These can include a Required property which the page can check during validation stages, or a ConvertCase property that can convert the case of the text to either all upper or all lower when focus leaves the control. Yet another example of a useful inherited control can be a button that contains an extra property called ConfirmationMessage. Setting this property to something other than an empty string can pop up a confirmation dialog when the button is clicked. Later in this article, I'll show you how to develop this custom button control.
This type of custom Web control gets its name because it directly renders HTML straight through the rendering engine. The control typically doesn't contain any other controls, thus focusing all its power and speed towards rendering the HTML that will ultimately decide how the output of the control looks on a Web page. Rendered controls work by overriding certain methods of its base that will control the fine-grained rendering of HTML tags and attributes. These controls can handle page postbacks by implementing some interfaces which give them the ability to raise events and/or check data values during that action. Because everything is controlled at a fine-grain level, there can typically be a bit more work involved when developing complex rendered controls. The proper naming, styling, and event handling of a rendered control's contained HTML elements must all be handled through an extensive amount of code. I'll talk about the advantages and disadvantages of this type of Web control after I describe composite controls.
A composite Web control is a control that contains one or more other Web controls. This control relies on the rendering ability of the Web controls it contains, acting as a container mechanism, deciding where to place said controls by providing framing HTML code around them. This will make a lot more sense when I show you how to develop one later. Because composite controls instantiate one or more (possibly many) child controls, the general consensus is that they can become a little heavy as far as rendering performance is concerned. Now, before you let such a negative statement sink in too deeply, let me share from personal experience what I consider the advantages and disadvantages of composite controls vs. rendered controls, as well as when each should be used.
I acknowledge the fact that rendered controls certainly do render faster than composite controls. This is because they are writing HTML directly through the rendering engine. At the same time, I feel composite controls are more straightforward to develop. If you know how to use the Web controls that Visual Studio provides for you then you're halfway there in developing composite Web controls. In defense of composite Web controls and their slower rendering, if you're developing a Web Form and place several Label and Textbox Web controls on it, you are going to take a performance hit similar to rendering one Web control that contains a similar set of Labels and Textboxes.
This leads me to how I make my decision as to what type of Web control I am going to write. If the control I need to develop is one in which I'll use a lot of instances on a page, I typically use a rendered control approach. If I am developing a control that will have a more complex UI and will typically be used once or twice, maybe even three times on a Web page, then I choose a Composite control. I haven't forgotten about the first type I described, the inherited control. I use these for controls such as those described in the examples I named when I explained the control to you. They are typically simple extensions of already existing controls. Notice I said "simple extensions" not "extensions of simple controls." You can inherit a very complex composite control and provide further functionality for it in the extended class.
As far as performance is concerned, you also need to take into consideration the target sites for your control. Internet sites usually are bit more performance-conscience than Intranet sites. You can certainly write any composite control as a rendered control, though it will probably take more time and a lot more code. This is where the other "performance" comes into play your performance as a developer and the time constraints you may have upon you. I use composite controls as the "Declarative" approach to my ASP.NET development, breaking down my sites into smaller, more manageable components which consist of you guessed it, Web controls.