I spend a reasonable amount of my time writing software for Microsoft's .NET platform, and on the whole I have to say that it's a pretty neat bit of kit. Okay, perhaps this is because its predecessor was a pile of crap and all .NET is really doing is the stuff that should have been there years ago (such as proper sockets support) which Unix has had for years. But to be fair to our mates in Redmond, some of the new Web Services gear, and the new ADO functionality, is actually pretty useful.
Imagine my disappointment, then, when having been impressed with the desktop application development stuff (VB.NET, C# and so on) I started to play with ASP.NET.
Microsoft has, however, missed two tricks with ASP.NET.
First, the concept of forms. It's not hard to see that there's a kind of correlation between a "form" in a desktop application and a "page" in a Web application. A desktop application's wizard isn't all that dissimilar from a Web application's page set the user sees one form at a time, and can switch between forms by clicking on buttons. In a desktop application you achieve this by creating a number of forms and instantiating them (and changing their status to "visible") as required. Oh, how I'd love to define my websites in this way and have the system allow me to instantiate pages and flag them as visible/invisible as required.
As it is, Microsoft has gone half-way to where I want to be, by providing the concept of a "panel"; this is an area on a form that can be flagged as visible or invisible and which, to be fair to Bill, does kind of get you some way toward the utopia that I've just described. The problem with using panels is that instead of having a collection of forms, each with its respective boxes, buttons, checkboxes and whatnot, you end up having one form with an unmanageable pile of panels. It works, but it ain't pretty.
The second trick they missed is that when you're using ADO the data access components of .NET in ASP.NET, you can't carry a connection from page to page.
Allow me to explain. In a desktop .NET application, you can open a database connection when the program runs, and then you can refer to this connection from anywhere in your program (assuming you've declared the relevant variable sufficiently liberally). The connection can stay open for the entire session. This is great, because the new stuff that has arrived with .NET includes some neat memory-based data handling routines. So you can load a bunch of data, fiddle with it to your heart's content, then tell the ADO routines: "Go and update the database as you see fit to reflect the changes I've made." It'll figure out what INSERT, DELETE and UPDATE statements it needs to execute.
In an ASP.NET world, you can't do this. Each page access requires the developer to open a connection, do some work, then close the connection. Although .NET does some nice connection caching in order to keep overheads down, it's a royal pain in the neck to have to keep opening and closing connections. Surely, Microsoft could have devised a way for connections/datasets to remain resident within the server's memory and for the executing code to be reattached to a prior connection when it reappears? As it is, developers have to find their own sneaky ways around the problem.
I can't help wondering if ASP.NET was a bit of an afterthought maybe Microsoft spent too much time getting the desktop development world right. I do hope, however, that at some point in the (preferably near) future they'll take a nice big step further along the road to making their Web technology appear as stateful as today's desktop technology. And if it lets me define each of my pages as a form, and share data connections between them, I'll be an extremely happy developer.
Find your next job with techworld jobs