Last post Jan 29, 2010 02:38 PM by HeartattacK
Jan 29, 2010 12:38 PM|barrydorman|LINK
Unless I'm mistaken, I believe the only way to create a custom server control is by inheriting from the Control class. Or, of course, inheriting from another class built on top of Control (such as WebControl, etc). I dug through the System.Web.UI source
code one time and came to the conclusion that this was the case. Anyway, I'm wondering why there isn't an interface for developing custom controls against? Something like an IControl interface that only forces us to implement the required functionality to
render (maybe ID, Render method, etc.). I hate being forced to inherit a bunch of properties from the Control class that may not be needed or work properly in the context of my custom control. I'm wondering if anyone else out there agrees that something of
this nature should be built into the framework?
Jan 29, 2010 02:38 PM|HeartattacK|LINK
I wouldn't agree to that. Webforms has a very complex control lifecycle and if there were an IControl, you'd probably have to implement quite a few methods to get it working. That's not why I disagree though.
Interfaces are one of the most overused aspects of OOP, while abstract base classes the exact opposite. Having a Control base / abstract base class doesn't prevent the use of polymrphism or abstraction, but it has one great benefit - extensibility.
Once you ship an interface - that's that. It's fixed. Changing an interface would require changing every line of code that uses that interface. When it comes to client apps using the .net framework, Microsoft can't expect to even hope of changing ALL code
using a certain framework interface. But why would that be necessary?
Consider some new framework feature that's being brought into asp.net 4.0 and beyond. Suppose it requires that Control or IControl support a new method. If Control is a base class, MS can just go and add the method to the base class. If IControl is an interface,
you can't do that. Simply adding a method to an interface is not at all a solution. You'd then need to create a new interface and anybody wanting to use the new features will need to change their code to reference the new interface. That ultimately violates
why you were using an interface in the first place.
In fact, there's a very real example of this matter in something we use very very often. Streams in .net 1 did not support timeouts. In .net 2.0 they did. This was achieved by adding stuff to the Stream base class. Any code referencing Stream would still
work, but Streams supporting timeouts could use the extra features. This enhanced extensibility while preventing a huge portion of code from needing an upgrade / becoming obsolete.
Yes, Control does have a bunch of properties, but they very well might be necessary for the webforms lifecycle. You might consider using html controls or even switching to asp.net mvc if you want more control.