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: PreSendRequestContent
My “over-idealistic” principles lead me to know these points:
- The ASP.NET Web Forms
Pagelifecycle consists of events that primarily allow granular control over Server Controls.
- The ASP.NET Web Forms
Applicationlifecycle 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
Pageevents into three groups:
Loadevent ‘groupings’ are divided into three logical granules
EventComplete. For example the
- One important Application-level stage in ASP.NET is getting
AcquireRequestState) where the
Page.Request(and, according to Joe, the
Page.Response) object is instantiated. Also, according to Joe, the
Page.IsPostBackproperty is set here.
PreInit, there is no View State set yet.
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
Control.Initevent fires for each child
InitCompleteevent 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.”
PreLoadevent represents the time when View State is reconstituted (so it has a logical relationship with
SaveStateCompletewhich fires at the end of the
LoadCompleteevent is a granular opportunity to handle any communication among child controls.
EnsureChildControlsfor the Page and child controls.
PreRenderCompleteevent is a granular opportunity to handle any data binding issues.
Renderevent is the obvious one.
Unloadevent 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.
- “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”