Conventional Events – The Daily WTF

Now, I would argue that the event-driven lifecycle of ASP .Net WebForms is a bad way to design web applications. And it’s telling that the model is basically dead; it seems my take is at best lukewarm, if not downright cold.

Pete inherited code from Bob, and Bob wrote an ASP .Net WebForm many many ages ago, and it’s still the company’s main application. Bob may not be with the company, but his presence lingers, both in the code he wrote and the fact that he commented frequently with // bob was here

Bob liked to reinvent wheels. Maybe that’s why most methods he wrote were at least 500 lines long. He wrote his own localization engine, which doesn’t work terribly well. What code he did write, he copy/pasted multiple times.

He was fond of this pattern:

if (SomeMethodReturningBoolean())
{
    return true;
}
else
{
    return false;
}

Now, in a Web Form, you usually attach your events to parts of the page lifecycle by convention. Name a method Page_Load? It gets called when the load event fires. Page_PreRender? Yep- when the pre-render event fires. SomeField_MouseClick? You get it.

Bob didn’t, or Bob didn’t like coding by naming convention. Which, I’ll be frank, I also don’t like coding by naming convention, but it was the paradigm Web Forms favored, it’s what the documentation assumed, it’s what every other developer was going to expect to see.

Still, Bob had his own Bob way of doing it.

In every page he’d write code like this:

this.PreRender += this.RequestPagePreRender

That line manually registers an event handler, which invokes the method RequestPagePreRender. And while I might object to wiring up events by convention– this is still just a convention. It’s not done with any thought at all- every page has this line, even if the RequestPagePreRender method is empty.