For many of us, ASP.Net has signified a new era of application development. The more we learn and experience the power and productivity of ASP.Net, the more impressive it continues to be. But Microsoft has already identified areas where improvements can be made, and common routines can be 'componentized'. These improvements have been made and will be available to the world of developers in the next version of ASP.Net, code-named "Whidbey". There are some truly exciting developments coming our way, and this article is an introduction to few of them!
Contributed by Justin Cook Rating: / 7 August 31, 2004
ASP. Good ol' ASP. The server-side solution that all of us became familiar with back in the day. Yes, it was almost as readable as a Dr. Seuss book, and very forgiving if you forget to declare a variable or even call it with the proper casing! But aside from its simplicity, the drawbacks are too many, including poor performance, and the oft maligned 'spaghetti-code' style of scripting.
So, in marches ASP.Net. WOW! The improvements are unbelievable! The performance, the scalability, the reliability. So many ASP controls to contribute to Rapid Application Development (RAD), so much power to configure your applications in mere XML files! Not to mention the object-oriented programming approach, no wonder it has become the fastest spreading Web development platform in the world. But as with any first version of anything, there were areas that could do with some improvement, and areas that really needed improvement.
Enter Whidbey. Tall, dark and handsome, a pure center-of-attention kind of guy. The mysterious Whidbey is in actuality the next release of ASP.Net, boasting a wide spectrum of new features and improvements that will no doubt take the development world by storm. This is not a complete re-write as was ASP.Net to ASP, therefore the learning curve won't be quite as severe. And not only that, but 100% backward compatibility is promised, a little assurance for our already strained brains, as we can ease or rush into the new code at whichever pace we can handle.
Keep in mind please, that at the time this article is being written, there is no publicly available download of the platform. So the information in this article is based on the culmination of information from MSDN, www.asp.net, forums, and any other rogue sources that could be surfaced. By the time of the first stable release, there will no doubt be enormous amounts of information available, but hopefully I can provide you with a taste, an appetizer if you will.
One word: speed. I guess that's always been Microsoft's methodology - find the common features, common patterns, and common code that not-so-common people (aka programmers) spend those countless hours coding, and give a way to do it faster. Much faster in fact.
For instance, most of us have spent some time developing a user creation/management/login system. I remember first outlining on paper the process I wanted to take them through, how to catch mistakes and bad log-ons. Then the hundreds of lines of code -- that was fun. I was somewhat happy that I'd built it in a somewhat modular fashion so that I could reuse it. But I would have been much happier if Whidbey was around at the time!
Right out of the box, we can jump into the web application administration tool, and run through the security setup wizard. Very, very quickly we can be administering the users/members on our site. Once they're in, the next (built-in) steps are to administer roles and permissions.
But then how difficult is it to implement the login interface into our application? How many lines of code? Guess. No, really, guess! The answer: 0 lines of procedural code, 1 server control in the form of <asp:login>. Incredible, amazing, and simply unbelievable! But it just keeps getting better, with pre-built components to handle forgotten passwords, easily differentiating between logged-in and anonymous users, and more.
Taking this all to the next level, Microsoft is providing a 'complete' personalization framework, allowing us to easily and rapidly incorporate a customized user experience into our applications. Out of the box the system is able to store and persist such data as user information and preferences, using Access or SQL as data-stores, depending on the size of the site. And naturally we can extend the personalization framework to meet our specific needs.
Something else we can look forward to on a site-maintenance front, are what Microsoft has called 'Master Pages'. These work in conjunction with 'Content Pages' to form a fairly slick system of template management. This is a far deeper topic than this article could hope to cover, but you can look forward to digging far deeper in a short while.
It also seems that a lot of attention has been given to data access, and for good reason. Data controls in ASP.Net such as Repeaters and DataGrids simplified our lives immensely, becoming very popular. But while the DataGrid gave us incredible power with moderate flexibility and minimal code, there were noted efficiencies that could be put in place. Anything from simply removing those two redundant feeling lines (DataSource & DataBind) of code, to providing an entirely new control, called the GridView control. This is more or less a supercharged DataGrid, overhauling a few features of the DataGrid, and then going one giant leap further by providing component-based data filtering and selected line highlighting, again no need for additional code!
I've also seen hints and allegations of built-in test servers and completely mobile enable ASP.Net controls. You've really got to give credit to the ambitious minds behind the ASP.Net team! But really, the changes I've mentioned so far primarily deal with you and I, the developers. What can administrators look forward to?
The power we're given over ASP.Net 1.x in simple XML configuration files is fantastic. But a somewhat hampering disadvantage lies in the fact that the very nature of the XML format behooves us to learn pages and pages of tags, each one with it's plethora of properties and attributes. And of course we forget the vast majority of the tags, and are headed right back to the documentation if we want to customize the security of our application for instance.
Obviously we're much more accustomed to working with graphical interfaces, not having to configure absolutely everything in raw text. Whidbey plans to cater to us in this regard, providing a much-needed MMC snap-in to work with the XML files. Phew, breathe a sigh of relief!
Another area identified as needing enhancement is caching. It was very interesting to see the very granular level of control we were afforded in ASP.Net 1.x, being able to cache pages, individual controls, and even collections or datasets! Well, one huge improvement we'll see is that now we'll be able to inherit from the CacheDependency class, and create our own unique cache dependencies. There's a pretty cool example on MSDN of creating a dependency based on an RSS feed. That's the kind of customizability (I still think I've made that word up) that developers enjoy, and now we'll have it.
Something else to look forward to, if you're using SQL Server 7 or higher, is SQL Cache invalidation. This is the means by which we can invalidate cached items based on changes within our database. And then one more update to anxiously await: Post-cache substitution. This will allow us to more-or-less bypass the output caching for strings that we wish to dynamically generate at run-time. Perhaps the least weighty of the three new cache toys, but useful nonetheless.
What's the Secret Code?
Both administrators and coders alike can look forward to new code compilation features. There is a new code-behind model, giving us the ability to have partial classes, defining different parts of a class in more than one file, all of them being combined by the compiler. One of the advantages here is a much more collaborative approach, it is now easier to share the development. Another major change in this model is that now Web Forms and the code-behind classes can both be compiled at run time. This signifies that we can make a small change and have it reflected, without rebuilding the entire project.
I think one of the biggest drawbacks in ASP.Net 1.x for me was the initial wait time involved in compiling the application when the first user hits your site. With Whidbey, we'll be able to circumvent that lag with In-place batch compilation. We can just browse to our site root with a special 'precompile.axd' handler, and your application is forced to compile.
Something very interesting, and especially beneficial to those of us who jealously protect their code, or 'intellectual property', is called precompilation for deployment. Through it we can create an executable version of our entire application, and distribute it without any source code. That's Microsoft for ya! I wonder how Open Source supporters feel about this feature...
Conclusion
The conclusion of the matter, everything having been heard is: if you like ASP.Net, you'll love Whidbey. Microsoft if moving faster than a speeding locomotive with this platform, and it may seem difficult to keep pace, but it's no doubt worth it. I, for one, am looking forward to more information on the platform (but would much prefer to get the SDK).
Implement Gzip and Deflate Compression in ASP.Net
