Webforms lessons learned the hard way (Part 1)
I’ve been spending a lot of my days in Webforms the last two years. In this post I want to share some best practices I’ve learned the hard way over these years. A lot of MVC developers might think this post comes a bit late (who still cares about Webforms?!), I do think (in the real world) a lot of the ASP.NET developers are still using Webforms. This post is directly targeting them.
Keep your pages light
There are a few things where you should pay attention to.
Most of the times the
the number one performance killer. Although most developers know storing
a lot of
ViewState on the page has issues, and that there are numerous
developers don’t take the time to think about the
Viewstate. I don’t
blame them. Persisting the
ViewState to another medium is not as easy as
it should be. The
Viewstate is enabled by default, disabling the
Viewstate on each control is a hassle.. In ASP.NET 4 the
ViewStateMode will make it much easier though. Once the users start complaining about performance, you are too late. I really encourage you to start thinking about the Viewstate as early as possible. Only use it when you need to persist changes across
Postbacks. You will be surprised how little you really needs to persist.
Updatepanels are great controls, but you should apply them wisely. Don’t blindly wrap your whole form in an
Updatepanel. Think about which part of your page really needs to be refreshed. The less HTML and
ViewState (!) coming back from the server the better.
Stay away from the designer
Creating pages using the designer doesn’t work on so many levels.
The Design view doesn’t always give a correct representation of how the page will look like when it’s rendered by the browser.
Using drag-and-drop, databinding wizards.. does not end well. I have a big problem with defining datasources in the ASPX markup. In my opinion the ASPX markup should be as clean as possible. It should serve as a view, and as a view only. Another downside of defining your datasources in your ASPX markup is that your application tends to be more fragile.
Let me prove this by this example..
In this example I’m binding a List of FireStationEvents to a GridView. Notice the TypeName and SelectMethods are strings.
<form id="form1" runat="server"> <div> <asp:GridView ID="gvEvents" runat="server" DataSourceID="odsEvents"> </asp:GridView> </div> <asp:ObjectDataSource ID="odsEvents" runat="server" SelectMethod="Load" TypeName="WFDemo.BusinessLogic.FireStationEvents"> </asp:ObjectDataSource> </form>
A few weeks later I decide to change the methodname Load to LoadAll. I
rebuild my solution and all is good. I publish my site to production, and a few
hours later I get a critical bug report assigned to me. After looking
into it, I discover I forgot to change the
SelectMethod property of the
DataSource. Loading the page throws an unhandled Exception at runtime:
ObjectDataSource 'odsEvents' could not find a non-generic method 'Load' that has no parameters. One small refactoring made the application fail
big time and I didn’t even have a clue.
Stay posted for Part 2 tomorrow! What are some of your Webforms lessons learned the hard way?