But problems remained with the ASP.NET 1.0 release, not an entirely unexpected situation given it was, after all, a 1.0 product. Developers found themselves writing a lot more code than they thought was good, and it was more difficult than it should have been to keep presentation and business logic well-partitioned and separate.
With ASP.NET 2.0, the ASP.NET team has continued to lead the way in making developer’s daily lives more enjoyable. The main theme of ASP.NET 2.0 seems to be “write less code”. In this article, with homage to David Letterman, we will count down my top ten favorite features of this new runtime. (Feel free to imagine the top ten list being enthusiastically read by Bill Gates, but of course, in your imagination he will only be reading the topics themselves—I will be reading the actual explanations.)
With no further ado, we begin, as always, with:
10) Application-wide registration of custom controls.
One of my biggest complaints about custom controls (and this was true of both UserControls and custom controls from a custom assembly) was that you had to put a “<%@ Register %>” directive at the top of every .aspx page from which you wanted to declare an instance of the control.
One of the main purposes of custom controls was to be able to use them from multiple .aspx pages in one application. Since controls typically encapsulate elements like menus, site navigation etc., it seems counterintuitive to me that in order to reuse that code, you have to add something to each and every page. But in ASP.NET 1.0, there has to be one Register directive for each assembly/namespace combination and one for each UserControl. If you need to add a new custom control, you have to go into every page where you want to use it, and add it manually.
In ASP.NET 2.0, you can add the Register directives to the web.config.
namespace="JonIsHappyNamespace"/>
You might wonder, if I was so worked up over it in ASP.NET 1.0, why it is number 10 on my list and not number 1? To be fair, despite my ranting, it was annoying, but not really life-threatening. It usually wasn't too hard to find the problem in the first place, and a simple cut-and-paste operation usually fixed the problem in seconds.
9) Programmable Configuration.
This is really a .NET runtime improvement, but it is still a big win for ASP.NET. The web.config file contains all the configuration information for an ASP.NET application. In ASP.NET 1.0, in order to change something (like a database connection string in the AppSettings element) you have to open the web.config file in the text editor of your choice.
With the new version, you can go into the configuration programmatically (without having to resort to manipulating the XML directly) and change the settings of your ASP.NET applications. This makes building things like installers, administration modules, and pages much easier.
8) Web Part controls.
Even though the personalization craze of the web has somewhat died down in recent years, there still are plenty of situations in which you will need to expose customization of pages to your end users.
With Web Parts, the ASP.NET team has given us a way to do that without writing any additional code. The WebPartZone control is used to define an “area” of the page that can be customized. Each zone can be made up of multiple parts which can be a ContentWebPart control, a custom control, or a UserControl. Used in conjunction with the WebPartManager controls, you can give your end users the ability to change where the controls in their page are displayed.
7) Posting to other pages.
One programming paradigm that ASP.NET 1.0 developers had to get used to was that the HTML forms in ASP.NET 1.0 had to have their action attribute refer back to the page that created the rendered page.
This wasn’t so much a limitation on functionality, since with Response.Redirect or Server.Transfer, moving a user from one page to the other was just a matter of maintaining the page’s state for the second page to retrieve. But it was a nuisance just slightly above the @Register directive on the annoyance scale.
ASP.NET 2.0 gives controls that cause a post-back to the server the ability to change the action of the form in the HTML page, causing the page’s state and data to be posted directly to an ASP.NET page other than the one that created it.
In the ASP.NET where you are declaring the server-side controls you set the PostBackUrl property to the aspx page you’d like the form to submit to.
In the second page you can retrieve the data the user inputted into the HTML form rendered by the first page by accessing the PreviousPage property and finding each control you’d like to get data from.
6) SQL Cache Dependency.
The ASP.NET 1.0 HttpCache class was a great feature for maintaining application-level state. One of the coolest features was the ability to create a dependency between an object you placed into the cache with another object, a file, or a directory.
Since frequently the object that you put into the cache related back to a table in your database, probably the question I got asked the most often when lecturing on ASP.NET was whether an object put into the cache could be invalidated when the underlying table changed. The answer in ASP.NET 1.0 was no. The new answer is yes.
To make this work, you first have to configure the SQL Server instance using the aspnet_regsql.exe command line tool. Then create an instance of the SqlCacheDependency class and add that into the Cache object when adding your data to the Cache.
5) Master Pages.
Using implementation inheritance was a cornerstone of the ASP.NET 1.0 model. Each .aspx page was compiled into a .NET class, and System.Web.UI.Page was that class’ eventual base class.
One oft-used technique in ASP.NET 1.0 was to create a “master page class”. This class derived from Page and generally had all the common functionality that each and every .aspx page in an application needed to use. It was trivial to get ASP.NET to use this class as the base class for all classes generated from your .aspx files.
Since ASP.NET is a framework to create user interfaces, the downside of this “master base class” model was that any server-side controls that were added dynamically via this class wouldn’t appear in the .aspx file designer in Visual Studio .NET.
In ASP.NET 2.0 there is a new feature called Master Pages. Master Pages are essentially ASP.NET syntax in a file with the .master extension. A Master Page can be created and serves the same purpose as the “master base class”. There are two main differences with the Master Page model.
One, the .master pages are visually designable. Not only that, when a .aspx page uses a Master Page, the visual elements from the Master Page are displayed in the design view of the .aspx page – grayed out.
Two, the Master Page isn’t used as the base class for the .aspx file.
4) Visual Studio .NET project model.
One complaint that was heard around the world about ASP.NET 1.0 wasn’t really an ASP.NET problem, but a Visual Studio .NET (VS.NET) problem. Although ASP.NET supposed a number of different compilation and deployment models, VS.NET was fairly myopic in its view of how everyone should develop ASP.NET web applications. VS.NET’s model wasn’t wrong for every scenario, but it was wrong in enough instances to warrant a fairly bad rap when developing ASP.NET.
In ASP.NET 2.0, VS.NET (specifically VS.NET 2005) is much more flexible. It is flexible in terms of what part of an ASP.NET application may be open in the IDE at one time (no more solution files). VS.NET 2005 allows you to use a “codebehind” file or not, it is up to you, where VS.NET 2002/2003 both strictly enforced the “codebehind” file model.
3) Visual Studio .NET /ASP.NET compilation model.
In close connection with item number 4, VS.NET 2005 also frees the intrepid developer to compile at will. In fact, late compilation is the norm with 2005, which again is the opposite of the 2002/2003 model.
Part of this new lax view towards compilation goes hand in hand with new features built into ASP.NET 2.0. ASP.NET 2.0 takes advantage of the new feature built into C# and the CLR itself which allows a class to be defined in multiple files. Essentially, instead of “codebehind”, we now have “codebeside”, in which the class created from the .aspx file gets compiled into the same class that can exist in another file. This straightens out some of the weird object-oriented weirdness that sometimes ensued because of ASP.NET 1.0’s derived (.aspx ) base class (“codebehind”) model.
Also with ASP.NET 2.0 there is a command line compiler (aspnet_compile) that allows you to precompile a whole ASP.NET application. This feature is also exposed with a specialized handler which can be found at the precompile.axd endpoint in your application.
2) Provider model.
When the ASP.NET team looked at the code being written in the real world, they saw many chunks of code they felt they could build into the runtime itself. Many of these chunks need some data to back up the UI. Of course the ASP.NET team couldn’t choose a data source for every application, nor should they. So they used a layer of indirection.
This layer is known as a provider. A provider sits between the UI piece (the ASP.NET server-side control) and the data (which could be an ADO.NET data source, an XML file, or something else). The provider generally derives from a specific base class and that base class has methods that the UI piece can call to get the data necessary to render itself. ASP.NET 2.0 ships with providers for the most common types of data. If you have a different data source, you are free to build your own provider.
One standout example is membership. For membership, ASP.NET 2.0 ships a provider for Access and SQL Server, and a set of controls that allow logins, account creation, account editing, password reminders, etc. Building a gated web site with these new controls and a provider is really a snap. Expect to see more of this functionality unfold over time.
1) Declarative Databinding.
In ASP.NET 1.0, Databinding was one of the top features. Freeing developers from looping over rows of data and concatenating strings to generate HTML by allowing a control to just take a data object and run with it, with the rendered HTML being created based upon properties set on the control, was a genius idea. The only slight problem was that in order to make Databinding work, we still had to write code.
In ASP.NET 2.0, they introduce the concept of Declarative Databinding, which essentially allows you to declare the properties you want on your data source with the same declarative model you use to declare the server-side controls themselves. Datasource objects are created in the same way as server-side controls, by dragging and dropping them from the toolbox, or by adding the declaration to the .aspx file. Once configured, a datasource can be bound to a data-bound control.
Clearly, there are a lot more than just 10 new features in the ASP.NET 2.0 release; we could easily have turned this into a Top Twenty, Top Fifty or even Top One Hundred list, had we wanted. ASP.NET marks a huge new set of functionality, driven by customer demands and requests, and your Top Ten list will likely differ from my own, depending on your experience and history with ASP.NET. But in the meantime, while you're building your own list, try starting with these 10—I think you'll like these new features just as much as I do.
No comments:
Post a Comment