The code in Listing 2 connects to the database, using the ADO Recordset object to retrieve some records, then builds an HTML string made up of a collection of check boxes. Of particular importance is the use of the StringBuilder object. .NET treats strings as closed and immutable objects. Although high-level languages offer operators such as + and += to concatenate strings, using such operators isn't the most efficient way of concatenating the strings. Because strings are immutable, when you concatenate two strings, your code just creates a new string of the appropriate size and places the contents of the two input strings into it. Especially in a Web-form scenario, using the StringBuilder object to build strings incrementally is the recommended technique because it always appends to the first string without creating a new string object every time.
Should I Stay, or Should I Go?
The fact that you can use ADO objects from within .NET applications doesn't necessarily mean that you always should. Importing ADO classes into a .NET context might save you from a radical porting of existing ADO applications because you just reuse your database skills and code, although in a new application context. However, it doesn't save you from having to carefully review the existing code. You need to consider two factors before you decide whether to stay with ADO or move to ADO.NET.
One major factor that can influence your decision is the wide array of languages supported on the .NET platform. The three most important .NET languages are C#, Visual Basic .NET, and JScript .NET. C# is a new language available only with .NET. Visual Basic .NET has a lot in common with Visual Basic (VB) 6.0 and VBScript, but it also has several new features and many new default behaviors that could easily break existing code. Of the three, JScript .NET most closely matches the set of features of its unmanaged, pre-.NET counterpart (i.e., JScript). However, little ADO code has been written with JScript.
Most existing ADO code is written in VB and, consequently, isn't totally compatible with Visual Basic .NET. In addition to new constructs and a new vision, many little changes divide VB and Visual Basic .NET. (See the sidebar "VB vs. Visual Basic .NET," for a summary of the main differences between VB and Visual Basic .NET.) Overall, choosing to stick with ADO and Recordsets doesn't guarantee that your code will remain unchanged in the .NET world.
The second factor to carefully consider is .NET data binding—that is, the ability to bind data to UI controls. Storing your records in a legacy data container such as the ADO Recordset doesn't let you take advantage of .NET-specific data-bound controls. Among these controls are a few—such as the DataGrid control, the DataList control, and the DropDownList control—that can really change the face of your applications, instantaneously making the look and feel more user-friendly while increasing overall developer productivity.
From Recordsets to DataTables
Let's see how to convert an ADO Recordset object into an ADO.NET object that you can more easily integrate with .NET applications. The code in Listing 1 uses a manually written While loop to scan a Recordset and produce a list of check boxes. In native ADO.NET code, you can obtain the same result with code that's surprisingly simpler and more compact, as Listing 3, page 40, shows. Note that you need to include the System.Data.OleDb assembly to use the class OleDbDataAdapter—the class that transforms the Recordset into an ADO.NET object.
The code in Listing 3 converts the Recordset into an ADO.NET object—the DataTable—that you can then bind to any controls that support data binding. Although not functionally identical, the DataTable object can be considered the ADO.NET counterpart of a disconnected Recordset object. In ADO, you obtain a disconnected Recordset by using a static, client-side cursor.
You accomplish the Recordset-to-DataTable conversion by using the Fill method of the OleDbDataAdapter object:
DataTable dt = new DataTable();
OleDbDataAdapter oda = new OleDbDataAdapter();
oda.Fill(dt, adoRS);
The Fill method populates the DataTable object with the contents of the specified Recordset object. While performing the operation, the Fill method creates any needed columns and adds rows. If primary key information exists, the Fill method matches any new row with any existing row. If it finds a match, it replaces the existing row with the new row. If no match is found or if no primary key information is available, the Fill method simply appends the Recordset row to the DataTable object.
Prev. page
1
2
[3]
4
next page 
