As I mentioned earlier in this book, a goal for Microsoft ASP.NET 2.0 was a 70 percent reduction in the amount of code. To the extent that this goal was met, it was because of new controls that eliminate a great deal of coding. For instance, the DataSource control, covered in Chapter 5, "Data Binding," eliminates much of the procedural coding required by previous versions of ASP.NET to provide data to controls. The GridView control, also covered in Chapter 5, allows fairly complete display of information from the database without any procedural code. In Chapter 7, "Web Forms User Security and Administration," you will learn about a new set of controls that allow you to perform almost all tasks associated with identifying, registering, and logging in users without any significant code. This is the power of controls: the ability to encapsulate a chunk of functionality and then have it reused, by yourself or other developers.
Custom controls, created specifically for an application, or perhaps better yet, for a suite of applications, allow you as the developer to encapsulate chunks of functionality required by your applications, just like the controls included with ASP.NET 2.0. The job of creating an application can be reasonably split among several developers, with each developer concentrating on creating specific controls or on tying controls together to create an application.
For instance, I once worked on a large system (not using ASP.NET or Microsoft SQL Server) with several unusual requirements. First, the application needed to communicate with a database that used unusual data types in certain areas. One was a date/time type that used a string in a particular format, rather than the DateTime type provided by the database. The development environment provided a variety of rich controls for interacting with dates, but those dates had to come from the database as DateTime types. So that all eight developers on the team didn't have to become experts in the details of this particular part of the system, I was tasked with creating a control that completely encapsulated handling of the date and time; the other developers could simply drag the control onto their forms. When bugs in the control became apparent (as, unfortunately, sometimes happens), I was able to address the problems, and when the application was next built, the fix was applied to all forms that used the control.
Compare this to a scenario in which each developer works out an individual solution on each and every form that he or she creates. Different developers might address a problem in subtly different ways, each with their own set of bugs. A perfect, bug-free solution would be ideal, but in the real world, a single consistent solution, even with a bug or two, is the next best thing. Custom controls allow you to create such consistent, if not perfect, solutions to the problems specific to your application.