Reusability applies to ASP.NET code mostly in terms of server controls, which are the atomic elements of these Web pages. You can expect two main advantages from a custom control: new functionality that replaces, restricts, or extends existing controls; and encapsulation of some common settings and behaviors that limits the amount of code necessary to build a solution.
In this chapter, I started the discussion with code-behind files as a solution for separating code and layout. Next, I covered user controls as a way to assemble several distinct controls with the goal of building aggregates that behave as a whole control. Have you developed a company-wide logon dialog box? Did you spend hours building a project-specific grid? Have you finally gotten your long-awaited progress bar? User controls offer a way to make all this code really reusable and not just injectable via cut-and-paste methods in host pages. User controls are ideal for building software components in which UI elements work in conjunction with back-end code. Together, they provide a suite of behaviors that is publicly exposed and programmable through properties and methods.
You can always employ user controls to write non-UI components, but doing so would be a poor design choice. Think of user controls as sealed components, not inheritable components, that are good for aggregation. If you need more flexibility than this, try custom controls, which are new Web controls built to inherit in pure object-oriented style from existing Web controls. In this chapter, I described custom controls as the programming technique that weds the true power of inheritance with the encapsulation of boilerplate code and common settings. I closely examined custom controls in the context of the DataGrid control.
Chapter 6 focuses again on the extremely versatile DataGrid control and the more advanced solutions you can build and consolidate by employing user and custom controls.