RPGDevNet

A Paradigm Shift in ASP.NET Application Architecture

By Tim Daniels

ASP.NET application development is undergoing a paradigm shift that will alter the architectural foundation of application design. Moving application processing from the server to the client is the simplest way to describe this change. More specifically, this means moving user interface centric processes, from the web server to the browser. This change not only affects system architects and website designers, it also changes the way developers design and create browser-based applications. Developers will have to give more consideration to architectural concerns than ever before.

At a technology level, this paradigm shift means that the current ASP.NET application model, based on postbacks and view state, is being replaced with an alternative architectural model. The new model is a combination of technologies focused on enhancing the end user experience in the browser. These technologies include; AJAX, JavaScript, jQuery and Service Oriented Architecture. For the developer, this means that server side controls will give way to AJAX and JavaScript based components running in the browser. Silverlight will also play a major role in this model. The ASP.NET Model View Controller (MVC) design pattern, which eliminates server side controls, also figures prominently in future web-based development.

What is driving such a dramatic shift in ASP.NET application architecture? End users are becoming more and more sophisticated; demanding more from web based applications in terms of content, work flow, graphics, animation, data access and rich interactive experiences. They are also becoming more intolerant of poor response to their requests. Regardless of network latency, architectural limitations and technological limitations, end users are demanding a more responsive web. The solution is to exploit the processing power and data caching capacity of the client, and drive as much processing and data manipulation as possible into the browser, along with reducing the payload size and number of round trips to the server.

The content for this article is based on two books I’ve been studying. Microsoft ASP.NET and AJAX: Architecting Web Applications by Dino Esposito and Developing Service-Oriented AJAX Applications on the Microsoft Platform by Daniel Larson. You will find these to be excellent references as you explore the future of ASP.NET application development. Also, although the spec isn’t yet completely feature-complete, read about what Microsoft has on tap for the upcoming ASP.NET 4.

Customers

By Rene Rodriguez

I was recently reading Karl Seguin’s “Foundations of Programming” ebook when I came across a sentence that reminded me of my first software development consulting job, eons ago. At the time I had been going to graduate school and took a break to think about my dissertation (which I ended up not finishing, but that’s another story). I was back home, had landed a part-time teaching job at a local college, and was looking for something else to do. My brother was a consultant with several customers in town; he had written an application in Clipper for DOS (bonus points if you know what I’m talking about) which he adapted to each of his customers. So I asked my brother if there was anything I could help him with. He told me the brother of one of his customers wanted a little program about lotto combinations. “Cool!”, the mathematician in me said. So the guy told his brother what he wanted, who in turn told my brother, who told me. Yeah. I know what you are thinking and you know where this is going, but the program looked so simple I couldn’t believe the description I got was anything different from what the guy wanted.

What the customer wanted

I finished the program after a couple of days of hacking away with Turbo Pascal. I agreed to meet with my brother’s customer and his brother to deliver it. I demoed it to them and he said “that’s not what I wanted…”

“What do you mean?”

He proceeded to show me his notebook, filled with number combinations, frequencies, graphs, and more, and explaining to me what he wanted the program to do for him. After the meeting I was angry, mostly at myself for not taking the time and caution to talk directly to the guy in the first place, which brings me back to the sentence I mentioned at the beginning:

The client knew far more about his or her business than I did. Not only that, but it was their money and my job was to make them get the most out of it. As the relationship turned more collaborative and positive, not only did the end result greatly improve, but programming became fun again.

And that’s exactly what happened: we met a few times afterward, developed a great working relationship, and programming the requested changes was fun to do.

The lessons I learned, work together with your customer and respond to changes, have served me well. I haven’t encountered a software project that didn’t require customer input and changes as the project progresses. Furthermore, I found out I was empirically Agile, as these lessons are embodied in the Agile Manifesto and are core to the Agile methodologies. If you are interested in reading more, one of my favorite blogs on Agile is James Shore’s “The Art of Agile” , which advocates XP and contains very valuable bits of information on the programming craft.