Being More Professional about Referring to ASP.NET Web Forms
A recent job interview with a very, very interesting company in Marina Del Rey, gave me the opportunity to review my way of approaching ASP.NET Web Forms. My way of approaching ASP.NET Web Forms in a professional conversation is deliberately disruptive and easily offensive. I want to offend “thought leaders” in Microsoft IT shops that may claim to appreciate jQuery and ASP.NET MVC but they actually do not and would actually prefer to work within the theory behind ASP.NET Web Forms. I don’t want to have a bait-and-switch kind of work-day-hell situation where I’m hired for an ASP.NET MVC/jQuery future but stuck in an ASP.NET Web Forms present. Simultaneously, I am willing to work with ASP.NET Web Forms as long as it is clear to me that no religious affections for Web Forms coming from the culture of the shop.
One red flag signifying such 1990s-based religious fervor is a request from an interviewer asking me to recite, from memory, the ASP.NET Page
lifecycle and/or the IIS application lifecycle. Too many Microsoft shops use these rote memorization stunts as intelligence tests—and I have always been disgusted with such mis-measurements. But my disgust has prevented me from really thinking about an authentic response to this question that is respectful of my principles/theories and not ‘easily’ offensive to my inquisitors.
Instead of memorizing this from ASP.NET 2.0:Application: BeginRequest Application: PreAuthenticateRequest Application: AuthenticateRequest Application: PostAuthenticateRequest Application: PreAuthorizeRequest Application: AuthorizeRequest Application: PostAuthorizeRequest Application: PreResolveRequestCache Application: ResolveRequestCache Application: PostResolveRequestCache Application: PreMapRequestHandler Page: Construct Application: PostMapRequestHandler Application: PreAcquireRequestState Application: AcquireRequestState Application: PostAcquireRequestState Application: PreRequestHandlerExecute Page: AddParsedSubObject Page: CreateControlCollection Page: AddedControl Page: AddParsedSubObject Page: AddedControl Page: ResolveAdapter Page: DeterminePostBackMode Page: PreInit Control: ResolveAdapter Control: Init Control: TrackViewState Page: Init Page: TrackViewState Page: InitComplete Page: LoadPageStateFromPersistenceMedium Control: LoadViewState Page: EnsureChildControls Page: CreateChildControls Page: PreLoad Page: Load Control: DataBind Control: Load Page: EnsureChildControls Page: LoadComplete Page: EnsureChildControls Page: PreRender Control: EnsureChildControls Control: PreRender Page: PreRenderComplete Page: SaveViewState Control: SaveViewState Page: SaveViewState Control: SaveViewState Page: SavePageStateToPersistenceMedium Page: SaveStateComplete Page: CreateHtmlTextWriter Page: RenderControl Page: Render Page: RenderChildren Control: RenderControl Page: VerifyRenderingInServerForm Page: CreateHtmlTextWriter Control: Unload Control: Dispose Page: Unload Page: Dispose Application: PostRequestHandlerExecute Application: PreReleaseRequestState Application: ReleaseRequestState Application: PostReleaseRequestState Application: PreUpdateRequestCache Application: UpdateRequestCache Application: PostUpdateRequestCache Application: EndRequest Application: PreSendRequestHeaders Application: PreSendRequestContentMy “over-idealistic” principles lead me to know these points:
-
The ASP.NET Web Forms
Page
lifecycle consists of events that primarily allow granular control over Server Controls. -
The ASP.NET Web Forms
Application
lifecycle consists of events that primarily allow control over security Authentication and Authorization.It follows that any ignorance I might have about these lifecycles implies that: -
I am inexperienced with using Server Controls—especially implementing custom controls.
-
I am inexperienced with using View State.
-
I am inexperienced with using advanced security scenarios with ASP.NET—especially implementing ASP.NET Membership/Roles/Profiles.What too many Web Forms people sitting across from me in an interview don’t care to respect is that my inexperience with Server Controls and View State is by design. However, my lack of experience with ASP.NET Membership/Roles/Profiles is a sad consequence of my deliberate de-prioritizing Server Controls and View State. My career-level decision to essentially defer learning about these features of ASP.NET in order to go into ASP.NET MVC is the right future-focused strategy—no amount of sophomoric snickering will change that—but to get a job in the present I need to know a little more about the older, more proprietary features of ASP.NET.
Joe Stagner Actually Talks about ASP.NET Page Lifecycle
Instead of listing a bunch of events or showing a colorful poster of events, Joe Stagner of Microsoft actually talks about the ASP.NET Page
lifecycle. When one is “forced” to talk about this subject, it becomes more human—therefore more relevant. Here are some points gleaned from Joe’s talk:
- It may be best to classify
Page
events into three groups:Init
,Load
andRender
. - The
Init
andLoad
event ‘groupings’ are divided into three logical granulesPreEvent
,Event
andEventComplete
. For example theInit
grouping isPreInit
,Init
andInitComplete
. - One important Application-level stage in ASP.NET is getting
Request
state (AcquireRequestState
) where thePage.Request
(and, according to Joe, thePage.Response
) object is instantiated. Also, according to Joe, thePage.IsPostBack
property is set here. - During
PreInit
, there is no View State set yet. - During
PreInit
, any dynamic server controls or master pages can be instantiated here. Any profile/theme properties can be set here. - Joe makes a point to mention that during the
Init
event, theControl.Init
event fires for each childControl
of thePage
. - The
InitComplete
event is a granular opportunity to handle any View State issues. From the documentation: “Use this event to make changes to view state that you want to make sure are persisted after the next postback.” - The
PreLoad
event represents the time when View State is reconstituted (so it has a logical relationship withSaveStateComplete
which fires at the end of thePage
lifecycle). - The
LoadComplete
event is a granular opportunity to handle any communication among child controls. - The
PreRender
event callsEnsureChildControls
for the Page and child controls. - The
PreRenderComplete
event is a granular opportunity to handle any data binding issues. - The
Render
event is the obvious one. - The
Unload
event is not so obvious to me—but it should be: this is when the page is just about to be returned to the client so it’s a time for cleanup.What should be authentically memorable to me is that these lifecycle events are where developers interact with all of the features of ASP.NET. So a developer that has memorized the lifecycle is one who has used almost all of the features of ASP.NET extensively (repeatedly, maybe violating DRY principles)—or just some dude with great memorization skills.
Related Links
- “More Unsung Microsoft Technology: the HTTP Handler (.ashx) Story Is Rarely Told ‘Correctly’”
- “ASP.NET Life Cycle”—the official MSDN documentation (that should update itself)
- “Custom Membership, Role Providers, Website administration tool, and Role based access to individual files”
- “ASP.NET Application Life Cycle Overview for IIS 7.0”
- “ASP.NET 4 Videos: The Official Microsoft ASP.NET Site”