Living .NET...

Why I don't like ASP.NET anymore

When I first started using ASP.NET (back in the .NET 1.0 days), I was in awe of the sheer capabilities it offered. For a humble ASP/VB developer, this was a welcome change. The Page object model seemed to be a work of art. “Code-behind” seemed to be one of the coolest things.  

Eight years down the line, my perspective has slowly started to change. All of a sudden, I have started to question the very design of ASP.NET (at least the object model and the Page Lifecycle). I have started to feel that the design is simply over-complicated. Let me give you examples of where I feel this pinch: 

1)       Code-Behind is always a mess

For ASP developers, developing screens using C# (or VB.NET) was a boon. Spaghetti code wasn’t there any more. All the power came in the form of code-behind. I liked code-behind to start with. But as and when we started to develop complex web applications (with rich UI), the code in code-behind files simply got worse by the day.

Web Client Software factory and the MVP pattern came in to reduce this mess to some extent. But I suppose, they arrived a bit too late. By that time, you already had applications with thousands of lines of code in each code behind file. WCSF and MVP only do so much. To date, I have never seen code behind classes which are not a mess. No matter how hard you try, you cannot keep code tidy. I know it is just not me, as I see hundreds of applications in the community which have the same plight.

Have a look at this piece of code, which I simply couldn’t do anything about. I have an editable grid with two editable columns – one a dropdown and the other is a text field (date). In this event, I am basically:

1.      Binding a list to the drop down
2.        Adding a delete command to each row, which is enabled conditionall
3.        Disabling the fields if the record is not a new one.

protected void gvReports_RowDataBound(object sender, GridViewRowEventArgs e)
{
 if (e.Row.RowType == DataControlRowType.DataRow)
        {
            DropDownList reportTypeList = (DropDownList)e.Row.Cells[0].Controls[1];
            reportTypeList.DataSource = _reportTypes;
            reportTypeList.DataBind();

            Models.Report report = (Models.Report)e.Row.DataItem;

            Button deleteCommand = (Button)e.Row.Cells[2].Controls[0];

            if (report.CanDelete)
            {
                deleteCommand.OnClientClick = string.Format(
                "if(!confirm('Are you sure you want to untag this report?'))return;");
            }
            else
            {
                deleteCommand.Enabled = false;
            }

            TextBox reportDate = (TextBox)e.Row.Cells[1].Controls[1];
            reportDate.Text = report.ReportDate.ToShortDateString();

            if (report.ReportID > 0)
            {
                reportDate.Enabled = false;
                reportTypeList.Enabled = false;
            }
        }
 }

I don’t know about you, but I simply don’t like the above code block. Without hefty comments, you wouldn’t have a clue what is happening in this block. Help me make this better. Don’t even bother to ask how I did the validations for the fields in this grid. 

2) Spaghetti Code will not go away

One of the banes of ASP was spaghetti code – server script and client script being mixed together. ASP.NET removes most of the pain, but not all of it. I find myself bringing in server script in many places. Here is an example:

      ASP.NET randomly generates control ids at runtime when controls are placed in containers or they are in pages having a master. To access these controls on the client script (to do validations, changing style etc), you could end up doing something like this:

var divReports = document.getElementById('<%= reportsSection.ClientID %>');
divReports.style.display = 'none';              

3)       No Client Side Object Model

No matter how powerful the server side object model, tons of code still needs to be written in JavaScript. The bigger problem is that ASP.NET controls don’t really have a client side object model which mirrors the server side object model. Therefore, you end up either writing a lot of spaghetti code as shown above or hacking the DOM which the server side controls creates. I see that many 3^rd party controls (like Telerik, Infragistics etc) actually offer a client side object model. I am not sure why it was not offered by the ASP.NET server controls to start with.

 4)       Painfully complex page lifecycle

For people who have developed “Portal” like applications, they would more than agree with me that the code would be horrendously complex, especially the container page which hosts the user controls. There are so many subtleties in the order of the events between the page and the user controls; you would get lost debugging through it. ViewState and master page add to the spice. Sometimes you begin to think that the idea of System.Web.UI.Control was a bad one. 

I have provided a few examples why I have started to dislike ASP.NET. I strongly believe MVC is the right way to develop ASP.NET applications. But unfortunately, it has arrived way too late for ASP.NET developers and the damage has already been done. Moreover, application stakeholders would have concerns to develop stuff on MVC as there is not much 3^rd party control support as of now. In other words, developing rich UI with MVC would just be too big a challenge to deal with. Be that as it may, code behind will stay for some more time to come, and that is unfortunate.