- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Isn't that method some sort of Delegate bullshit? Reminds me (in a much worse way) of Model-View-Presenter which actually was a pretty good WebForms pattern if you had to use WebForms.
Admin
I'm not sure what you mean by "Delegate bullshit". Delegates are the .NET feature which allow you to pass around references to methods. When you attach a handler as usual, using the
+=operator, it adds a reference to the given method to the delegate value (delegates are "multi-cast", which is a WTF, BTW). The ASP.NET WebForms simply auto-emits such+=statements behind the scenes for you, when it encounters methods named according to the convention, likePage_Load. It has a "pre-compilation" step - it takes .aspx/.ascx/etc. markup files, their corresponding .aspx.cs/etc. C# files, converts all of that into C# (markup is converted, convention event handlers are attached, etc.), and that resulting C# is then built as usual.Admin
Ironically this one is optimized away by the .net compiler since the very beginning (the IL compiler, not the C# compiler). So it is basically just boiler plate code written by a sloppy developer that prob intended to put additional code in those brackets.
Now the event handler one I don't really understand. Yes, it's the default naming convention, but if you have the wrong name, the code won't compile because the (multicast) delegate can't add a non-existing method. So it's actually perfectly fine to get rid of the underscore; some would argue it was a mistake by MS to introduce it in the first place but technically it's completely fine and in line with naming conventions.
Admin
.net came from the beginning with the observer pattern implemented as a language construct by events and multicast delegates. Now that is totally fine, though it has obvious drawbacks, especially when it comes to asyncronous code (if you are only familiar with Java, that's a magical thing that allows you to do multi threading without threads by using a state machine and context switching).
Now the only issue and big mistake was that delegates are the only construct for save function pointers; so basically a single cast delegate is a multicast delegate with one added function pointer. That obviously has performance implications - but in the old days, MS preferred simplicity over performance.
So the TL;DR is basically there is nothing wrong with single cast delegates or the direct language support of the observer pattern. However the combination of both in one language construct is questionable since the observer pattern has different implementations depending on architectural concurrency considerations.
Admin
As I often comment, the WebForms paradigm made sense when viewed in the context of the time. I agree it has not worn well over the eternity that is almost 30 internet-years, but that's due to a complete revolution in who we build apps since then.
It was conceived as part of Microsoft's very abrupt hard turn when they realized the future wasn't standalone local apps running on desktop PCs that might be on a basic LAN but rather was the internet in general and web sites in particular.
So how to port the dev experience of Win32 desktop programming to the web? And how to provide large scale commonality for the devs between .Net for desktop apps and .Net for website-based apps?
I'd argue they did a hell of a job getting that almost entirely right. In an era of dumb browsers and smart servers. Which is the polar opposite of today with smart browsers & dedicated mobile apps trying to connect to minimalist "dumb" servers designed for low overhead per request to maximize the ability to scale the server side cheaply by offloading as much work as possible onto the client device.
Admin
I think it would still make a lot of sense today if you're a relatively junior developer tasked with developing a simple departmental form-filling app that you might have used Access or Windows Forms for.
It allows you to get all the advantages of a web app without having to juggle 2 apps at the same time (i.e. the client and the server) . the closest equivalent is probably NextJS which has (IMO) a much higher cognitive load on the developer