Introduction to User Controls

I l @ ve RuBoard

Chances are, if you are currently an ASP developer, the term code reuse conjures up images of a seemingly endless series of include files that has come to be known in Web development circles as spaghetti code. Aptly named, this phenomenon can be the byproduct of ASP include statements to include either subroutines or inline presentation markup used by more than one ASP page. While providing some benefits, such as allowing changes in included files to cascade across the site, the include statement makes debugging more difficult. Most of us have felt the pain of stepping through another developer's code searching through a chain of included files looking for a particular function declaration.

ASP.NET attempts to alleviate these headaches with the advent of user controls. User controls in their simplest form are really nothing more than a way for you to componentize your Web forms by combining one or more existing controls to function as a unit. In the same way that classes encapsulate logic in OOP design, controls encapsulate functionality in GUI design.

It must be noted here that user controls are not the only way of encapsulating functionality when creating ASP.NET applications. In the next chapter, we will discuss creating ASP.NET Custom Controls and in which scenarios they are preferable to user controls.

Before we delve into the creation of ASP.NET user controls, let's look briefly at some scenarios in which they should be considered :

When UI elements are repeated often on many Web forms throughout an ASP.NET project. Like include statements, using user controls in this situation allows changes to cascade across the site.
For complex Web forms with many UI elements. Breaking up the Web form into smaller controls makes maintenance easier.
For team projects. Controls allow a natural division of work for team members .

Now, let's look at how we create user controls and use them in ASP.NET.

I l @ ve RuBoard