A Web Site by Way of WebControls
What the heck do I mean by that? Well, let me start by stating that while this article is not a course on custom Web Control development, it's important to mention a few points about this technology. The Web Controls that Microsoft and other parties provide are, at their root, classes. This means, of course, that they are programmable by any object-oriented techniques and coding style you may be accustomed to, and maybe some that you are not. Programming custom Web Controls in ASP.NET allow you to use object-oriented programming and various design patterns in a tier where you weren't really able to do so before, at least not extensively.
|Classic ASP did not have what developers now refer to as WebControls. Many developers, however, used to use COM components written in VB6 to receive information via method arguments and return HTML to render in the ASP page.|
Most people seem to think of custom Web Controls only in terms of component building and reusable tools that you can easily distribute to anyone for use in any Web application. While this is true, they are much more than that. My apologies to those of you who think I am stating the obvious, but believe me, I wouldn't be writing about this if I had not seen it, or seen the lack of it, to be more exact. Custom Web Controls do not have to be written with the whole world in mind, they can serve a single project (or a single corporation)
if need be.
This can serve three purposes: first, it can allow you to isolate visual components of your application and encapsulate them into controls. Right away, this eliminates code-clutter at the WebForm level, but it also encourages the second purpose, reusability. Depending on the functionality you give a Web Control (and not all of it has to be programmed in right awaysome may come as-needed), you can reuse it in other places within your application even if its appearance is radically different. I'll give you some examples later. The third purpose it serves is the ability to "object-orient" your Web development. As I said before, controls are classes. They can extend or be extended by other controls, they can implement interfaces, and they can participate in whatever design patterns you deem appropriate for your task.
Microsoft has indicated that using the FormView control in Visual Studio 2005 lets you create an entire data-entry/edit form with a Web Control. Declaring properties on that control will make the FormView appear and even behave differently. You can create your own custom Web Controls that contain other controls used to build a form, or a custom grid, or any combination of anything you need. This is called a composite Web Control and is simply a control that contains a hierarchy of other controls, thus encapsulating their functionality and exposing only what is desired. When designing and developing Web applications in ASP.NET, this Web Control, or "declarative" approach to my design has served me very well and has been really well-received by those who support my apps after I am gone (the life of a consultant).
At immediate glance, developing Web applications made up primarily of custom Web Controls may seem like more work than before, but think about this. How many times have you had to build multiple nested tables, each containing multiple cells, each containing specific controls such as labels, textboxes, or buttons? A "Web Control-approach" to development lets you break your WebForm into its components, allowing you to manage the visual aspects of a complex form much easier. The level of breakdown is, of course, entirely up to you but I'm going to demonstrate techniques I have used in the past. Though at first it may appear that these techniques add complexity, I think that after you get the hang of it, they actually reduce the complexity.
This example is going to take multiple steps so bear with me. I am going to illustrate how I have used custom Web Controls to separate my Web application into manageable parts, even though not all may be subjects for reusability. Say that I want to build a site that requires a data-entry form with a few fields on it: Name, Address, City, State, Phone, and E-mail. I could build these fields right on the WebForm, or maybe I could create a UserControl that I could later drop onto the WebForm.
Right away you can see that I would have to create 12 visual objects 6 labels and 6 textboxes. Some of these may be required fields so those would probably have a red asterisk to the left of the label. Suppose Name and E-mail were required; this would add two more labels to the form. To get things to line up properly I would put these controls in a table. I'd also add two more controls that are also pretty common to this scenario a heading and a submit button, which would bring my total control count to 16. No big deal; you've done this.
Let's take the first step towards making this a bit more declarative by introducing a Web Control approach. When I look at a form like this, the most common element I see is the group of controls that make up a field in the data-entry form. I am talking about the field label, the textbox, and the asterisk that indicates a required field. By creating a custom Web Control that encapsulates these three objects, I can clean up a great deal of the object clutter on the WebForm. A beneficial side-effect of creating this control is that you can reuse it just about everywhere in this site and in just about any other site you create in the future.