Design (and not big up front design) is necessary in server controls for one simple reason: this control you are building will not be the end all. Eventually, someone, somewhere, will need to extend your control. As an example, lets look at a very simple examination of the AdRotator control. First, the AdRotator has three methods which can be overridden (as do most server controls). OnPreRender, CreateControlCollection, and OnRender. When you inherit from System.Web.UI.WebControls.WebControl, you gain access to these methods and many others but those methods are outside the context of this brief tidbit. Hence, we have pretty much total control over the look and feel of the resulting control. There is one method, however, that practically prohibits moving the AdRotator control to a datasource other than an XML document: GetFileData. This method ONLY accepts a filename (string) argument. Now, I ask you, would it have been SO much trouble to overload this method and accept a XmlElement? If an overloaded GetFileData method
could accept an XmlElement argument, you could pretty much use any datasource you wanted, even if it would be ALOT of work on your part to keep the Xml and eventual datasource synched.
So, with a little forethought and consideration for the users of your controls, I think we will all be a lot better off. This is especially important in 3rd party controls. Microsoft, when they release a monumental effort like the .NET Framework and the base ASP.NET Server Controls, it would be nearly impossible to get every thing right. However, I can use only the .NET Framework and Notepad to create my own server controls and extend the existing ones. However, if I buy a 3rd party control that suffers from poor or incomplete design, the entire control is just a waste of money. It may meet my needs in 90% of all situations but I really looking for controls that meet my needs in 99% of all situations.