ASP.NET 1.x Inheritance Hooey
The image at left reveals my inheritance-based redesign away from earlier hooey. All of the “edit” ASPX pages inherit from the default ASPX page. So, now, I realize why Microsoft allows the word “visual” to be added to “inheritance” instead of just using the word inheritance with regard to ASP.NET 2.0 marketing fluff. (And I use the word ‘allow’ because Fritz Onion would not be able to use the term when writing for MSDN.) This acquiescence may be related to the following:
- In ASP.NET 1.x with Visual Studio.NET 2003, every code-behind ASPX page inherits from a base class. And just because
AutoEventWireup
isfalse
, does not imply that other “auto-wiring” is happening behind the scenes (more on this later). - One of the easily overlooked facts here—‘easily’ overlooked by me for at least three years—is that inheritance is always happening by default in ASP.NET Visual Studio Solutions. This is ‘easy’ to overlook because this inheritance really does not have a visual representation in the VS.NET 2003 designer.
- The visual Designer in Visual Studio 2003 demands that only one ASPX page can inherit from a code-behind class file. (This might cause strange confusion with the OOP term “multiple inheritance.”) I thought it would be a sign of ignorance to use the
ID
property of thePage
object to identify the only child of the code-behind class by file name—on the contrary: this looks like a useful statement in an inheritance design pattern. When an ASPX page inherits from its code-behind class—which, in turn, inherits from a default, page class, this default class will most likely need to identify the sub-classing ASPX page.
Hey, Bryan! All of those server control members declared in the code-behind class are declared as protected
so that its sub-classing ASPX page ‘magically’ overrides them through the auto-wiring powers of ASP.NET.