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 is false, 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 the Page 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.

rasx()