12 Ways to Simplify ASP.NET and Visual Studio

While at PDC this year I had an opportunity to interview a number of smart and engaging people. One of my guests was Scott Hunter (@coolcsh) who these days is responsible for WebForms, ASP.NET Data and seemingly much more. To my surprise Scott wanted to talk about what is coming after ASP.NET 4!

Taking a step back and looking at ASP.NET, tooling, data and the entire experience of working with the .NET stack Scott’s team and other groups in Microsoft are turning their attention to a single concept…


While I will refer you to the Pixel8 podcast, ASP.NET Simplicity and Performance with Scott Hunter, to hear the details about ideas his team is entertaining to make ASP.NET easer and perform even faster, I thought I would throw in my two cents as well. The following is my wish list of twelve improvements to ASP.NET and Visual Studio that would undoubtedly make development faster and easier.

1: Overload the DataBind Method

How often have you worked with data bound control and wrote code like this:

protected void Page_Load(object sender, EventArgs e)
this.grid.DataSource = foo;

Wouldn’t it be simpler if you could just call the DataBind method and pass in the data source?

You can do this easily today by implementing an extension method as I did here, but it would be nice to have this as a first-class feature of the BaseDataBoundControl class.


2: Implement IsFirstRequest Property

The whole notion of the IsPostBack property always seemed a bit awkward to me. More often than not you are using this property to evaluate it’s negative state – in other words trying to figure out if the page is running under the context of the first request. I suggest the addition of a property that is no more than the reverse of IsPostBack:

It’s a small thing, but I think it makes code a little cleaner to read.


3: Implement Application Name

Often developers need a way to display the application name to users. While setting up a globally-scoped class to handle this task is trivial, but it would be nice if there was a “Name” property off the page’s locally scoped Application property:

The value for this property would likely be saved in the web.config or Global.asax. Adding this feature may also help sort out a common problem that arises in using the membership provider when developers forget to define an application name. Visual Studio could auto fill this value with the “application name” from the create project wizard and then allow an override at any time.


4: Option to Categorize IntelliSense Members

Ever wanted to tap into an event of an object, but weren’t sure what the event name was? Ever wanted to know just what an object methods were while trying to learn a new API? What about trying to find out if there is a property for X? IntelliSense is an invaluable tool in it’s current form and Visual Studio 2010 adds some needed filtering behaviors for C#, but we can do even better.

It would be nice if IntelliSense had a way to display members in a categorical format:

Obviously this isn’t a feature you would want enabled at all times, but it would make working with new APIs much easier.


5: Bring XAML Data Binding Syntax to ASP.NET

David Fowler (@davidfowl) has been churning out some amazing blog posts all around the topic of data binding in ASP.NET. One of his recent posts included an exposition of DataBinding 3.0. Basically the latest iteration of data binding brings the XAML syntax to ASP.NET data binding.

This addition makes life easier because then you don’t have to worry about when you use the Bind or Eval syntax. Plus making a homogenous binding syntax among WPF, Silverlight, ASP.NET AJAX and ASP.NET WebForms makes working with the controls a natural task regardless of the platform you are working.


6: Parameter Attributes

When working with QueryString parameters requires some repetitious boilerplate code. Consider the following listing, which you have probably written thousands of times:

private string UserName
if(Request.QueryString["userName"] != null)
return Request.QueryString["userName"].ToString();
return string.Empty;

How much simpler would it be if you could just decorate the property with an attribute and the retrieval code is implemented automatically?

This approach doesn’t have to stop with the query string either. The same types of attributes may be available for :

  • QueryString
  • <li>Form Elements </li>
    <li>Context Items </li>
    <li>Session </li>
    <li>Cache </li>
    <li>Cookies </li>


7: WebForms Model Binders

One of the features that I immediately fell in love with from the ASP.NET MVC framework was model binders. With the updates to ASP.NET 4 granting total control over the client IDs of server controls, now WebForms needs model binders!

The pages could be strongly typed like MVC strongly typed views, or the designer could interrogate the control hierarchy and build the view model on the fly. Obviously we’d also need some hooks to tap into the flow to implement custom bindings too.


8: JavaScript Model Binders

Just as the server can benefit from automatic mapping of input controls to a model object, Ajax scenarios could be greatly simplified if there was a function to run on the client that automatically created a JSON object with all input values.

Consider a form like this:

With markup like this:

A model, or DTO if you like, could easily be constructed by querying the form and building the object from input elements.

There could even be special rules for certain controls like a select list. Sending the selected index, text and value as a group for the single control should provide all the information necessary to consuming resource.


9: Select the Location of ViewState

While ASP.NET 4 makes great strides to trim down a page’s ViewState it would still be nice to have explicit control over where the ViewState is rendered on the page. I’d love to see a server control that allows you to place the ViewState containers at a location of your choosing:

Now more times than not the best approach is to simply move ViewState to the bottom of the page, but having explicit control of the placement seems like the best scenario.


10: Disabling the Post Back Button

The ASP.NET runtime will not recognize a post back initiated by a disabled button so developers have had to concoct some clever ways to protect users from themselves. It would be nice if ASP.NET had a way to reliably disable post back buttons out-of-the-box.


11: Implement ASP.NET Configuration Console as Portable Area

Eric Hexter (@ehexter) recently blogged about the concept of a “portable area” where you can compile single controls controls or even up to entire workflows into an assembly to later include in an ASP.NET MVC or WinForms application. This approach is perfect for implementing the ASP.NET configuration UI generated by Visual Studio.

The portable area approach would decouple the screens from the layout seen in this screenshot and allow the pages to reflect the layout of your website. This feature would be perfect for exposing the membership functionality to admins, power users or even just the development team.


12: Script-Based Post Backs

On occasion when working with WebForms under the traditional post back model you may need to implement a JavaScript function that initiates a post back. Right now, the approach for executing this a hack at best. One the best ways I have seen to accomplish this is to add a LinkButton to the page and hide it from the user using CSS. Then you can view source on the page and use the __doPostBack call the LinkButton was using in your custom script – like I said real hacky :)

It would make life much simpler for the times when this functionality is required to have a method off the Sys namespace (or wherever appropriate) that posts back a WebForm. This is how it could look:

Passing a string into the function would tell the page which handler to map to in the page event lifecycle.

So there you have it. These are some of my ideas about how to make ASP.NET and Visual Studio simpler to use. Now tell me, what are yours?


  • I might use all of these at some point, but definitely would use #1 (Overload the DataBind Method), #7 (WebForms Model Binders), and #10 (Disabling the Post Back Button) daily.

    One addition would be the ability to bind an ASP.NET DropList to an Enum.

  • #2 is a good idea, and you could easily implement the "IsFirstRequest" as a getter property on your base form class even now.

  • Great article, I would use just about all of these features! Great stuff!

  • 2. IsFirstRequest sounds like a bad name. Without looking at the definition, does it indicate:

    a. that this is not a postback request;
    b. that this is the first time the current user has requested this page;
    c. that this is the first time the current user has requested any page in this application; or
    d. that this is the first time any user has requested any page in this application?

    6. Your UserName property is needlessly complicated:

    private string UserName
    get { return Request.QueryString["userName"] ?? string.Empty; }

    9. Moving ViewState to the bottom of the page would have unintended consequences. A user on a slow connection can cause a post-back before the ViewState field(s) have finished downloading, resulting in an error. There was a similar problem with the EventValidation field, particularly over SSL, which was fixed in SP1 by moving the field to the top of the form.

  • @RichardD

    IsFirstRequest would simply be the reverse of IsPostBack. I think you could ask the very same questions that you raise of IsPostBack. It would just be a manner of knowing the API. Now I will admit that 'IsFirstRequest' may not be the best wording, but something like it would be nice.

    As for the UserName... your code is certainly more succinct, but I'd like to see the attribute... still less code :)

  • Nice article..Its a good tutorial for ASP.NET learner.Hoping for more such articles in future.Thank you.

  • I just know I've seen *someone* use that IsFirstRequest approach somewhere before...

  • thank you!
    send it 2 ms!
    excellent add-ons
    how about programatic databinding? (i.e. txbLastName.Databind("LastName"))

  • @Yisman:

    I like where you are going with that, but how about an automatic mapping between the model and the controls? That way you wouldn't have to do it explicitly for each control.

  • This is awesome man ;) Great article.

Comments have been disabled for this content.