ASP.NET Simplicity -- When Is Too Much Simplicity a Bad Thing
1. A big cause of grief going around right now is the impact on real enterprise developers of the decision to have web projects not have project files. Yes, this was a decision made in the name of simplicity -- and for 99% of the web developers out there that ASP.NET targets it probably was a very good decision. But once again the problem is that this simplicity is being forced on the rest of us, and many of us enterprise developers really need many of the capabilities the project file gave us. Should MS have known better -- most definitely yes -- I for one tried to warn them about this very issue at the first Whidbey preview in October of 2002, and I think I was probably the one attendee that best represented real enterprise developers as opposed to authors and trainers.
2. Another "problem" that was introduced with ASP.NET v1 and is now getting worse is that MS gives us "rich" web controls with properties like backcolor, font, and width. Unfortunately, there are no such html attributes -- everyone of these properties is instead actually part of the html element's style. Yes I realize this simplifies things greatly for newbies, but all its done is "teach" more people that CSs isn't important -- and its made real CSS stylesheets much more troublesome to use in ASP.NET. Think I'm off my rocker? Did you know that the Calendar's Title CssClass did not work at all in v1 since no one ever bothered to test stylesheets adequately? Want another example? Did you know that WebPartZones, yes that new wonderful portal technology in ASP.NET v2, will not work with the CssClass properties -- and according to MS that's "by design" and "postponed"? I was really hoping to use WebParts, but all I had to do was try to use it with CSS stylesheets (don't most portals work that way) and I realize they are pretty much worthless -- not to mention take a look at the ugly html they produce. And what's the work-around for this you ask -- Themes and Skins. I know that Themes and Skins are one of the cool new features of ASP.NET v2, but have you ever stopped to think that they wouldn't be needed if we just used CSS stylesheets!
3. My last example is harder to explain -- its not really an issue with "postbacks" so much as a problem with the way most controls handle the postback to determine what to actually do. I'll use the ever popular ASP.NET Forums as an example -- specifically the moderator tools to approve a post or unmoderate a user. I'm looking at a post right now where the Approve link-button has the following link: javascript:__doPostBack('ContentControl$_ctl0$PostRepeater$_ctl0$_ctl0$_ctl0$Approve',''). So what's the problem? This is all based on the relative position of controls, and the data they are assumed to contain, instead of using the actual data key. Sure you can make an argument that its more secure to not expose the data key, but the problem is that without it there is no good way to reliably know what data we're supposed to be talking about! If you use viewstate to move all the data with the postback then its not a problem -- but of course we all hopefully know that moving all of the data in viewstate (the default though in most cases in ASP.NET) is not a good thing. So instead the data is re-queried on postback to determine what data goes with which control, and therefore what post should be approved in this case. But the data can and does change on a real website with lots of activity (hmmm, like the ASP.NET Forums)! So what ends up happening is that the wrong posts are often approved and/or the wrong users are often unmoderated (or we just don't bother to unmoderate anyone).
Now to their credit, they have fixed a lot of these issues in the ASP.NET Forums over the years -- the delete post link now uses the actual key for instance -- but many of these very real bugs persist. The standard method of not using the key is also not very performant, since even if you forget the case of data changing you still have to re-query the database just to do something (and then query it again to get the final set of data to display after the change) -- unless of course you put all the data in viewstate. Note that I do not want to imply that postbacks, viewstate, controls, or any other feature is inherently wrong -- I only want to point out that the simplification has went too far and can actually affect data integrity and/or performance if you use a lot of the defaults. For me this means that I never use the datagrid for more than the simplest of pages or prototypes (if even then) -- and that's really not even a burden once you've used the repeater a few times, or written your own "grid". But the problem persists (and most people don't even realize it) -- and just as bad there are now thousands of articles out there to help you figure out how to get around all the various short-comings of these simple controls. Why? Because this simplicity is great when it works, but unfortunately its teaching many web developers to never do anything else -- I can't even begin to count the number of "huhs" I get when I respond to questions about the datagrid that I don't know because I don't use it.
OK, end of post -- I hope I didn't lose everyone -- or make you think I've lost it. I really do love ASP.NET, and I do appreciate the folks on the MS ASP.NET team, and I do understand the needs for some of this simplicity so that they can reach out to a much wider pool of web developers -- I do not want their job. I just think that sometimes what is simple in the short-term or small cases ends up being anything but simple in the long-term or bigger cases -- so there needs to be a better balance in some cases to not make things too easy just because someone wants it that way. I encounter the same types of things even with my ORMapper -- why can't you just do this thing that would make my code go from 3 lines to 1 line, even though it will make other situations far worse -- that's not simplicity to me.