More WebForms roadblocks and a glimpse of hope

My previous post has gotten a lot of great feedback. Thanks everybody! I got some more important roadblocks that are worth noting. I am starting to think that having outlined the traditionally hard parts in ASP.NET development and later focusing on techniques for mastering them might turn helpful to many people. OK then, here we go.

Andy Stopford started out by bringing up ViewState. Being an easy source of many performance issues is almost a non-issue. To me, ViewState is a classic example of a leaky abstraction. It tries to make you think that your controls never get unloaded and HTTP requests do not actually exist. All you have to do is handle some events and configure controls in there. Yeah, right! That abstraction does not cover a lot of scenarios and pretty soon you find yourself thrown into the pit of lost state data, odd control behavior, and hard-to-find bugs. Like it or not, ViewState is here to stay, and going through a good book or a good article series is a must for all new developers. Going through the required reading and approaching dynamic control loading with some discipline typically deals with all ViewState-related problems.

Probably the hardest thing to do in ASP.NET is MVC. The page architecture does not help much when you want to separate your application concerns. Many people will just go with the flow and end up with that 5-KLOC code-behind class. I still think you can achieve a good level of separation of concerns and realize a nice MVC-based architecture for your app... again, with some discipline.

Mike Yeaney brought up AJAX and especially how ASP.NET has never been designed with AJAX-based apps in mind. You have to jump through hoops if you want to do better at authentication and error handling, so that they work better with XMLHttpRequest calls. Things are getting better with ASP.NET AJAX. At the very least you get support for web services, working with profile data and authentication. I strongly advise that anyone trying to create rich user interfaces starts with that.

Ruffus brought up the out-of-fashion rendering of many of the built-in controls that makes it hard to create accessible pages. Accessibility is a big requirement these days and is getting harder and harder to ignore. Nevertheless, having a truly-accessible site will require that you learn the tricks of the trade and carefully craft your rendered markup. Doing this with custom ASP.NET controls or with a home-grown framework looks like the same amount of work. Still, I'd lean towards the control-based solution.

I fully agree with Wally that you have to really know what you are doing when ditching WebForms. It is highly unlikely that you are smarter than the Microsoft guys that designed the framework and, chances are, you are better off if you stick with WebForms and invest some time into learning how to extend the framework and overcome its limitations.

4 Comments

  • I was going to post this on the previous blog, but it makes just as much sense here:

    Unit testing of your web controls and pages is the biggest roadblock I have faced yet. I write (for the most part) library code (I am starting to write more and more web control code) for coworkers to use in piecing together a couple webapps. All of my code comes with unit tests that ensure everything is done to specifications (except for the new web controls). Then they go about using my class libraries on a page and inevitably make mistakes every once in a while (display the wrong column in a table, list a bunch of grant totals negative instead of positive, ...). Because of this they insist in having a team of testers that test the entire applications before every deployment to ensure no regressions occur since the last version.

    I have started looking into projects like selenium, but that appears to need the whole site available. So for your unit tests you would need to test the entire page at a time. It seems extremely difficult to render individual controls in order to test them.

  • Bill, I feel your pain. Web controls are one of the hardest thing to test on earth. Internally, at Telerik, we are using this tool one of our smartest colleague built to help with unit testing. The tool hosts ASP.NET in-process and allows us to simulate postback events, postback data, viewstate saves and loads, etc. It has been of tremendous help when testing tricky stuff like composite controls, templates, etc.

    I hope I can post more info on that and, who knows, maybe we can publish it someday.

  • This is a great blog! You share my sentiments about asp.net. Now after having written many asp.net apps I have gotten into my grove on how to make asp.net work with the web instead of trying to hide it and work against it. Maybe one day I'll find the time to write some things up. To be honest though if it wasn't for c# I would have dropped asp.net a long time ago.

  • Years ago, I was also in the mood to switch to LAMP, instead of fighting for ASP.NET in my company. Today we´re happy that we based everything on .NET/Microsoft-World (except the Database). And one reason for this are web controls. Although hard to test, hard to debug, it´s just a pretty nice architecture.

Comments have been disabled for this content.