ASP.NET Data Access

In this tutorial you will learn about new features in Data Access, Data binding, The XPathBinder, XPathBinder.Eval, Connection Strings, The factory class, Batch operations, Asynchronous Commands, SQL Bulk Copy, ColumnMappings, Enhancements to SQL Server 2005, ADO.NET Class Enhancements, DataTableReader, Serializing a DataTable, The XMLSerializer, RemotingFormat and Managing Views of Data.

ASP.NET 2.0 performs a kind of magic. It pushes ADO.NET objects to the backend and leaves the programmer free to use the access code inbuilt into a bunch of data source controls. Microsoft encapsulates a significant amount of code in the new Data source controls. In this tutorial we shall look at some of the enhanced data binding syntax that has been made available, storage of database connection strings and also enhancements to the ADO.NET object model.

Data Binding is a process of connecting a Web control to a data source element. The verbose DataBinder class of ASP.NET 1.x has been replaced by a class that demands a more compact syntax. It supports the generation and parsing of data binding expressions. The overloaded static method Eval uses reflection to parse and evaluate an expression against a runtime object. The Eval method includes RAD tools that enable the declarative placement of calls to the method feed properties’ dynamically changing values. The Eval as it appears in ASP.NET 2.0 is simply a wrapper around the DataBinder.Eval method and the base method is invoked using the default container’s data item. The method that is incorporated into the Page class is as under:

Protected object Eval(string expression)
{
Return DataBinder.Eval(this.GetDataItem().expression);
}

When this DataBind method is called the controls are pushed into a stack based mechanism that traces the current binding context for the page and the control is popped from the stack when the DataBind method returns. The syntax of the GetDataItem assumes a default Container.DataItem context object and the GetDataItem returns that object

The new Bind method provides a read and writes operation. Unlike Eval it works both directions and when a text property is read, the value is stored in a collection. Enabled data bound controls can then retrieve these values and use them to compose parameter lists of the insert or the edit command. This runs against the data source. The parameter name in the command must match the argument passed to Bind.

The XPathBinder class is similar to Bind but works on XML data. A significant improvement is that it can be associated with raw xml data unlike the version of ASP.NET 1.x. When bound to a templated control such as a DataList or Repeater and the same is bound to an XML data source, then, individual xml fragments can be bound inside the template using the XPathBinder object.

The new XPathBinder.Eval method accepts an XmlNode object along an XPath expression and evaluates it to return the result. The format string will have to be specified and the XPathBinder.Eval method casts the container object o IXPathNavigable. This is essential for the query to run and the XPath API is built to work with objects that provide the navigator class. The XPathBinder syntax assumes a default container context. This container context is the object that is tracked for the data binder. The output value is converted into a string and the XPathBinder.Eval gets a navigator object from the data source and evaluates the expression.

The select method of the XPath executes a query and retrieves a nodeset which is an enumerable collection of XML nodes. The collection can be assigned as a late bound value to a databound control. The results of the XPath query run on the container object are indicated by the XPathSelect keyword. XPathSelect assumes a default data item context object and a IXPathNavigable object has to be implemented if no exception is to be thrown.

.NET providers have been enhanced in Whidbey to provide support to factories and batch operations. Connection Strings are critical application parameters and contain sensitive data. Whidbey configuration files define a new section for holding connection strings called . The structure is as under:

< connectionStrings >
< add name=”ExForSysDB”
connectionString=”SERVER=…;DATABASE=…;UID=…;PWD=…;” / >
< add name=”ExForSysAccessDB”
conectionString=”~/DATA/ExForSysDB.mdb” / >
< / connectionStrings >

The contents of this section can be manipulated by using < add >,< remove > and < clear >. Each web.config file can be placed in the application directory and the collection of connectionStrings can be customized. Each string has an identified name and references the connection parameters throughout the application. These strings are also used to link to the other sections of the configuration files such as the section of < membership > and < personalization >. This section is a global and centralized repository of connection information.

Connection Strings can be retrived programmatically since they are defined in the Web.config file and loaded into the new ConfigurationSettings.ConnectionStrings collection. Any changes to the connection string parameters are not reflected in the page or business objects directly.

In ASP.NET 2.0 connectionStings can be stored declaratively. We will be dealing with this in greater detail in the next lesson of this series. For the present is it necessary to understand that the expression builder object helps create expressions that have syntax similar to the data binding syntax and are evaluated when the page compiles. The content of the expression is extracted, transformed into code and injected into the C# code of the page. The expression has two parts—prefix and value. It also has an underlying object –the expression builder. The expression builder decides on the prefix and also determines how to parse the value and expand it. It accepts a ConnectionString as a prefix and the name of the configuration entry as the value and expands the expression.

ASP.NET 2.0 gives a lot of importance to protecting sensitive data stored in the configuration system. Industry standard XML encryption is used to encrypt specific sections of the configuration file. However, this is optional and it can be enabled by referencing the section to be encrypted in the
< protectedData > section of the web.config file. The type of encryption can also be specified by selecting the required provider from a list of providers to be found in the < providers > section of the web.config file. The ASP.NET configuration API can be used to encrypt the content or the aspnet_regiis.exe can be used. Though managed configuration sections are eligible for protection, the section itself cannot be protected. Clear text is used to describe the behaviour of this section. Similarly sections consumed by the CLR from Win 32 code or from ad hoc managed XML parsers cannot be protected by this system.

ADO.NET 2.0 introduces a new class called the factory class. This class is derived from the base class DbProviderFactory. It represents a common entry point for a variety of services specific to the provider. The CreateCommand returns a provider specific command object. The CreateCommandBuilder returns a provider specific command builder object. The CreateConnection returns a provider specific connection object. The CreateDataAdapter returns a provider specific data adapter object and the CreateParameter returns a provider specific parameter object.

The Factory class also has a few static methods which are used to get the factory of a particular provider. The GetFactory method takes a string that represents the invariant name of the provider. This is hardcoded for each provider in the configuration file where it is registered. It gets the assembly class name information for the matching invariant name. Since the factory class is not directly instantiated, the GetFactory method uses a reflection to retrieve the values of the static Instance property on the factory class. The instance of the property is returned and thereafter any methods of the factory class can be called.

ADO.NET 2.0 enhances Batch operations. A new property has been introduced on the data adapter object that controls multiple records grouped together and sent to the DBMS. The UpdateBatchSize property has been coded in the DbDataAdapter class and is inherited by all data adapter objects. The default value of the property is 1. However, it is set to a higher value all modified rows are sent in a single batch. It is recommended that a bench mark size be set before a higher value is assigned to this property, as it can result in performance loss.

The profiler tool can be used to check on what happens when a batch is submitted. When batch processing is turned off a RowUpdating and a RowUpdated event is generated for each batch. Turning on batch processing, results in the behaviour of these events undergoing a change. Several rows are processed before an update is actually performed and several RowUpdating events are performed before a RowUpdated event is performed. The row property is null. The information can be accessed using CopyToRows method. This method fills an array of DataRow objects. The right size of the array can be determined by examining the RowCount property in the RowUpdatedEventArgs class. This returns the number of rows processed in a batch.

The SQL Server provider has received special attention. The features of the SQL Server 2005 have been fully exploited. Asynchronous commands, bulk copy, notifications, multiple active resultsets and support for user defined CLR types are some of the features that have been enhanced.