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 and Render.
• The Init and Load event ‘groupings’ are divided into three logical granules PreEvent, Event and EventComplete. For example the Init grouping is PreInit, Init and InitComplete.
• One important Application-level stage in ASP.NET is getting Request state (AcquireRequestState) where the Page.Request (and, according to Joe, the Page.Response) object is instantiated. Also, according to Joe, the Page.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, the Control.Init event fires for each child Control of the Page.
• 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 with SaveStateComplete which fires at the end of the Page lifecycle).
• The LoadComplete event is a granular opportunity to handle any communication among child controls.
• The PreRender event calls EnsureChildControls 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”

rasx()