Browse DevX
Sign up for e-mail newsletters from DevX


Top 10 Annotations and Remarks about the Wonderful and Powerful New Features in ASP.NET 2.0

This article discusses 10 features of ASP.NET 2.0 from a real-world perspective. It is not a core reference of classes and methods, but a user's guide with suggestions and trade-offs.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

hould you use DataGrid or GridView in ASP.NET 2.0? Is SqlDataSource perhaps more appropriate than ObjectDataSource for building a data access layer? Are cookies evil or is a cookieless solution worse? These are only some common questions that developers will ponder as ASP.NET 2.0 takes root. You'll still write a good deal of code in ASP.NET 2.0.

Don't completely trust those who say that ASP.NET 2.0 cuts 70% of the amount of code you're called to write. You'll end up writing more or less the same quantity of code, but you'll write code of different quality. You'll have more components and less boilerplate code to tie together pages and controls. Features like the provider model, data source controls, and master pages make coding easier and equally effective. But since there's no magic behind, you have to learn the implications of each feature you employ. In the end, ASP.NET 2.0 comes with code behind, not magic behind.

Compared to classic ASP, ASP.NET 1.x was no more and no less than a revolution. It changed everything—the component model, the syntax, the languages used to author pages, the runtime environment, and the tools to design and create applications. And like icing on a cake, ASP.NET 1.x endeavored with good success to remain as close as possible, if not compatible, with the old code and old way of devising Web applications.

Today, most evangelists and influencers tend to present ASP.NET 2.0 as a major upgrade to ASP.NET 1.x. I mostly agree with this point of view. Overall, ASP.NET 2.0 introduces new controls, enhances the runtime environment, is richer in functionality and more customizable, but is fully backward compatible and doesn't appear to developers as a brand new thing. Although extended, refined, and refactored, it's the same old dog that has been taught a lot of new tricks. So far, so good.

While this vision is logically correct, the amount of changes and improvements (read, the number of new tricks learned by the old dog) is astonishing. Let the numbers talk.

The core functions of ASP.NET are implemented in the system.web assembly. In ASP.NET 1.x, the system.web assembly counts 14 namespaces and 321 exported types. In ASP.NET 2.0, the number of namespaces grows up to 22, while the number of exported types almost quadruples, to 1121 types. Do you still want to call it a major upgrade?

Adaptive rendering is the process by means of which server controls generate markup specifically crafted for a particular browser.
In the end, ASP.NET 2.0 doesn't change the programming model and doesn't modify the pillars on which developers build Web applications with Microsoft .NET technologies. Everything else is different because it is a new feature or because it is the reworked and enhanced version of an existing feature.

The goal of this article is to provide an annotated overview of ten selected ASP.NET 2.0 features. You'll find dos and don'ts, whys and wherefores, and the rationale behind them. For obvious space constraints, I cannot provide a detailed description of the required syntax nor a step-by-step guide to the feature and its usage. If you need this kind of reference, either check out the online MSDN documentation or get a copy of Programming Microsoft ASP.NET 2.0 Applications Core Reference (Microsoft Press, 2005), which should be hot off the press by the time you read this.

#1—DataGrid vs. GridView
It's easy to guess that a couple of quite versatile data-bound controls will be a fixed presence in most real-world ASP.NET 2.0 applications—the DataGrid and GridView controls.

Both controls render a multi-column, templated grid and provide a largely customizable user interface with read/write options. In spite of the rather advanced programming interface and the extremely rich set of attributes, the DataGrid and GridView controls both simply generate an HTML table with interspersed hyperlinks to provide interactive functionalities such as sorting, paging, selection, and in-place editing.

Although customizable at will, grid controls feature a relatively rigid graphical model. The data bound to a DataGrid or GridView is always rendered like a table—in rows and columns. Nevertheless, the contents of the cells in a column are customizable to some extent using system-provided as well as user-defined templates.

The DataGrid is the principal control of most data-driven ASP.NET 1.x applications. Like all ASP.NET 1.x controls, the DataGrid is fully supported in ASP.NET 2.0 but is partnered with a newer control meant to replace it in the long run. The new grid control, GridView, is complemented by other view controls, including DetailsView and FormView. The GridView is a major upgrade of the ASP.NET 1.x DataGrid control. It provides the same basic set of capabilities plus a long list of extensions and improvements. When should you use one vs. the other?

For brand new ASP.NET 2.0 applications, choosing the GridView over the DataGrid is a no-brainer. For ASP.NET 1.x applications being upgraded and maintained, moving to the GridView doesn't pose any significant issues and, more importantly, it positions you well for future enhancements. In the end, the DataGrid control is over and is supported in ASP.NET 2.0 only for backward compatibility reasons so that existing applications can continue to work when simply ported and recompiled in ASP.NET 2.0.

Compared to the DataGrid control, the syntax of the GridView is largely similar but certainly not identical. The classes you use for binding columns have different names, for example BoundField and HyperLinkField instead of BoundColumn and HyperLinkColumn. In addition, the GridView supports more field types including ImageField and CheckBoxField for images and Boolean values.

The GridView control simplifies the implementation of some features such as the definition of edit and select buttons. To enable editing and selection, you simply set a couple of Boolean properties with the GridView, whereas the DataGrid requires you to add specific columns and handle related events.

Helper events that signal the creation of a new item, or the item's binding to row data, have been renamed too and also underwent some minor syntax changes. For example, The ItemCreated event of the DataGrid corresponds to the RowCreated event of the GridView. The event's delegate is different. In particular, the RowCreated event is a simple EventHandler delegate and doesn't carry any additional information about what happened. The event is a mere notification that a grid's element has been created. You have to figure out yourself which element was created. On the other hand, new properties return an object reference to each grid's element—header, footer, data rows, top and bottom pagers—so that you can easily check which one was created and decide how to proceed.

protected void GridView1_RowCreated( object sender, EventArgs e) { // Check if the footer row was created if (GridView1.FooterRow != null) { // Do something here } }

The GridView's RowCommand event matches the DataGrid's ItemCommand event and indicates when a custom column button is pressed. The DataGrid's event passes the index of the clicked button through the ItemIndex property. The GridView's event uses a different approach based on the CommandArgument property, as shown below:

protected void GridView1_RowCommand( object sender, GridViewCommandEventArgs e) { // Check the command name associated with // the button if (e.CommandName.Equals("Add")) { // Get the index of the clicked button row int index; index = Convert.ToInt32(e.CommandArgument); // Add the item to the shopping cart AddToShoppingCart(index); } }

The GridView allows you to cache the value of multiple fields for each displayed row. It is only one field—the primary key, if any—with the DataGrid. In the GridView, the DataKeyNames property (an array of strings) overtakes the DataKeyField property of the DataGrid (a string). Both controls support the DataKeys property which is an array of DataKey objects for the GridView and an array of strings for the DataGrid. Imagine you declare a GridView using this syntax:

In the code file page, you retrieve the productname field of the clicked row with the following code:

protected void GridView1_RowCommand( object sender, GridViewCommandEventArgs e) { if (e.CommandName.Equals("Add")) { // Get the index of the clicked button row int index; index = Convert.ToInt32(e.CommandArgument); DataKey data = GridView1.DataKeys[index]; ShoppingItem s = new ShoppingItem(); s.ProductID = data.Values["productid"]; s.ProductName = data.Values["productname"]; } }

So far I've just taken for granted that ASP.NET 2.0 comes with two distinct and different grid controls, outlined the main differences, and basically suggested when to use which. Summarizing, you should always use the GridView in new ASP.NET 2.0 code and as much as possible in migrated code. The DataGrid remains available in ASP.NET 2.0 mostly to ensure compatibility.

Could the changes and enhancements slated for the GridView have been implemented directly in the DataGrid?

The key difference between DataGrid and GridView is elsewhere. In ASP.NET 2.0, a new family of server controls makes their debut—data source controls. These controls have no user interface but supply data to data-bound controls. Data source controls reduce the quantity of code you're called upon to write in data-driven pages. Data source controls intelligently communicate with made-to-measure data-bound controls to provide data to display and save changes back to the physical data source in a two-way data binding mechanism. Simply put, the DataGrid and all ASP.NET 1.x controls were not designed to fully support data source controls. The DataGrid, in particular, supports data source controls only for display. The DataGrid is not designed for two-way data binding. That's why Microsoft created a new grid control. Data source controls are perhaps the most powerful new feature in ASP.NET 2.0 and I'll cover them in more detail later.

What about paging and sorting? GridView and DataGrid work in a nearly identical way if both are bound to enumerable data sources like in ASP.NET 1.x. If bound to a data source control, the GridView control relies on the capabilities of the underlying data source control for paging and sorting. For this reason, the GridView control has no property to enable custom paging. If you need a custom algorithm to have the grid page through data, you have to code it in a stored procedure or a custom business class bound to a data source control.

Thanks for your registration, follow us on our social networks to keep up-to-date