Practical ASP.NET

Is There a Future in Server-Side Code?

Peter Vogel closes out his eight-part series on creating an AJAX-enabled ASP.NET application.

• By Peter Vogel
• 06/16/2010

At the very least, I prefer to use ASP.NET to control navigation through my site: dragging and dropping hyperlink controls on my page instead of typing anchor tags, using Server.Transfer/Response.Redirect, and cross-page posting to send the next page to the user are all easier with ASP.NET.

If I was creating 'stateful' server-side services (rather than the stateless WCF Data Services that I used in this project), I'd want access to the Session and Cache objects. I'm less interested in the ViewState object because, under the new "AJAX paradigm", I only postback when the user goes to a new page.

I'm enough of an "old-school" ASP.NET programmer that, should I want to create a textbox on my page, I'd prefer to drag an ASP.NET TextBox onto my page. As you saw in this project, when I wanted a dropdown list, I first used an ASP.NET DropDownList. That allows me to use skins, the various other style properties on the control and (as I demonstrated in my first project), the ASP.NET validation controls.

Right now, those server-side tools don't integrate well with the client-side tools I want to use from the AJAX library. Rather than providing an integrated solution for creating Web-based apps, Microsoft has two solutions working in parallel: one on the server and one on the client (and that's ignoring ASP.NET MVC as a third solution).

Having said that, typing the HTML for the drop down list isn't an onerous burden (in fact, you'll find it in the download):

<select id="customerList" class="sys-template" onclick="getOrders">
  <option value='{{CompanyID}}'>{{CompanyName}}</option>
</select>

So, when it comes to appearances I'm going to be far more dependent on someone who actually knows CSS than I am with server-side controls. I may actually have to break down and learn CSS.

Overall, the structure of my page isn't all that different: I've got about as many client-side dataContexts as I would have server-side DataSources, as many client-side dataViews as I would have, well, server-side DataViews. I have to type more things instead of dragging and dropping, but I guess that's not the end of the world.

What Peter Misses
What do I miss when working with client-side code? I miss IntelliSense, of course -- the dynamic nature of JavaScript probably prevents me ever getting the support on the client that I'm used to on the server. I miss using the Properties window with its list of all of the known properties (with their names spelled correctly) and, in many cases, the list of acceptable values. I miss Visual Studio's willingness to write out binding expressions for me instead of having to type them in character-by-character (and hoping I've spelled everything correctly). There's far less compile time checking in JavaScript than in the current state-of-the-art with server-side code and that's a real problem.

I'll also have more work to do in the "fit and finish" category. Right now, for instance, the area that displays Customer data initially displays my binding syntax until the data is displayed. I should make that invisible until I retrieve data. When I delete a Customer, I should remove the Customer from the DropDownList and make the customer area invisible until the user selects another Customer. That may not seem like a lot of work but that's taken care of for me if I use the server-side FormView.

Which just means, I suppose, that there's a market out there for client-side controls. Nevertheless, in the short term, my productivity is going to be lower.

On the other hand, I'm going to have a more responsive site that makes fewer demands on the server and generates less network traffic: It will support more users and run faster. Is the trade off worth it? I don't think that I have a good answer for that... yet.

Flux and Stasis
As I said at the start of this series, Microsoft's client-side strategy is in flux. The databinding mechanism that I used may be replaced by an extension to the jQuery core (Microsoft is one of several groups making proposals in this area and contributing resources to making it happen -- you can follow the discussion here and here). The adoNetDataContext I used will probably be replaced by a jQuery plug-in in the near future, for instance. Better integration between server-side controls and the AJAX library could turn up in a Service Pack for Visual Studio.

But, in the meantime, I bet I can use this technology to drive up my billing rate to the clients who want it...

But enough philosophizing. Next column: Back to the server-side world.