Practical ASP.NET
Building Better Client Internet Apps
Peter looks at the options for client-side development and the practicalities of leveraging ASP.NET.
The original paradigm for Web applications was the request/response cycle: send a request to a Web server along with any data on the page, have code on the server build a new page, send a response consisting of the new page back to the client, and (finally) have the browser redisplay the whole page.
The current paradigm still begins with a request for a page, but once that page is displayed in the browser, all subsequent activities are implemented as a conversation between the page and the server, using JavaScript and Web Services (at least until the user moves on to a new page).
Alternatives
You could make a case that, if you want to do this, the right route to take is to abandon the world of JavaScript and HTML and move to, well, something like Silverlight and/or .NET RIA Services. See my article on
.NET RIA Services on the server and
.NET RIA Services on the client for more on these alternatives. Honestly, that's probably a good idea and may even be where the world ends up. But until the Silverlight client is as ubiquitous as a browser, it's not an option for Internet applications.
In fact, it's hard enough to get a company's intranet developers to adopt non-browser based solutions -- and those developers have control over the user's computer. I have any number of people showing up to take my ASP.NET course who are exclusively building intranet applications. I suggest to them that they'd be better off creating ClickOnce Windows forms or Silverlight applications, and they nod their heads and ask when we'll be getting back to the HTML stuff.
You could even make a case that .NET 2.0 has already implemented the current paradigm: All of the DataViews support AJAX-like sorting and paging, implemented with a single property setting (provided you were careful about what other options you took with the controls). However, to load the initial data into the DataView, you have to post back to the server. It's not hard to image a case where the user specifies the data to display after the page is displayed in the browser. In the current paradigm, you don't want to post back to the server to get that data.
Leveraging ASP.NET
Fortunately, you don't have to. The tools for integrating server-side processing and client-side code are becoming increasingly prevalent, powerful and easy to use. My article in the December issue of Visual Studio Magazine,
Integrating jQuery, Web Services, and AJAX and ASP.NET, demonstrates how a combination of ASP.NET, client-side scripting with jQuery, and some Web Services can implement the current paradigm. The case study leverages a great deal of ASP.NET, including using the client-side code generated by the ASP.NET validators.
However, the case study in the article handles only one record on the page. In this column, over the upcoming weeks, I'm going to extend that case study to display multiple records by using the jTemplate plugin for jQuery. This is all available technology that you can start using right now. It's a very practical solution but, as you'll see, it's a solution that doesn't take much advantage of .NET.
Certainly, there are third party ASP.NET controls out there with extensive client-side support (personally, I've worked with Infragistics' AJAX-enabled controls). But I want the ASP.NET framework to support these client-side activities. As a consultant, I'm honestly tired of having to learn a new control set as I move from client to client.
.NET 4 will move in that direction. For instance, Microsoft is planning a client-side templating solution for ASP.NET that integrates, and leverages, DataViews (see Bertrand Le Roy's blog for more on this.
But until you're ready to migrate to .NET 4, I'll stick to the practicalities.
About the Author
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.