50
Using ADO.NET • Chapter 9
413
and speed. Because ADO.NET is based on XML, it only requires that a data
provider serve up the data in XML. Once you write your data access code, you
only need to change a few parameters to connect to a different data source.
ADO.NET is based on a connectionless principle that is designed to ease the
connection limitations that we traditionally had to deal with when creating dis-
tributed solutions.We no longer have to maintain a connection, or even worry
about many of the connection options that plagued us in the past. Since the
ADO.NET classes inherit from the same core of data access classes, it will make
switching data sources much easier and less troublesome.The core ADO.NET
namespaces are described in Table 9.1.
Table 9.1
Core ADO.NET Namespaces
Namespace
Description
System.Data
Makes up the core objects such as DataTable,
DataColumn, DataView, and Constraints, to name a
few. This namespace forms the basis for the others.
System.Data.Common
Defines generic objects shared by different data
providers, such as DataAdapter,
DataColumnMapping, and DataTableMapping.
This namespace is used by data providers and
contains collections useful for accessing data
sources. For the most part, we do not use this
namespace unless we are creating our own data
provider.
System.Data.OleDb
Defines objects that we use to connect to and
modify data in various data sources. It is written
as the generic data provider and the implementa-
tion provided by the .NET Framework in Beta2
contained drivers for Microsoft SQL Server, the
Microsoft OLE DB Provider for Oracle, and Microsoft
Provider for Jet 4.0. This class is useful if your pro-
ject connects to many different data sources, but
you want more performance than the ODBC
provider.
System.Data.SqlClient
A data provider namespace created specifically for
Microsoft SQL Server version 7.0 and later. When
using Microsoft SQL Server, this namespace is
written to take advantage of the Microsoft SQL
Server API directly and provides better performance
than the more generic System.Data.OleDb
namespace.
www.syngress.com
Continued
41
414
Chapter 9 • Using ADO.NET
System.Data.SQLTypes
Provides classes for data types specific to Microsoft
SQL Server. These classes are designed specifically
for SQL Server and provide better performance. If
we do not use these specifically, the SQLClient
objects will do it for us, but may result in loss of
precision or type conversion errors.
System.Data.ODBC
This namespace is intended to work with all
compliant ODBC drivers, and is available as a
separate download from Microsoft.
The Command, Connection, DataReader, and DataAdapter are the core
objects in ADO.NET.They form the basis for all operations regarding data in
.NET.These objects are created from the System.Data.OleDb,
System.Data.SqlClient, and the System.Data.ODBC namespaces.
Differences between ADO and ADO.NET
ADO is based on a binary format for data, with a database connection paradigm.
We were allowed to disconnect record sets in later versions of ADO, but this
required marshaling the binary representation of the data from process to process
and then reconstructing it into valid data formats.This limited us to tightly cou-
pled implementations with connection issues if we needed to operate through
firewalls, proxies, and so forth. Since ADO.NET is based on a textual standard
that does not require type conversion, marshaling, and special RPC ports for
transporting the data, Microsoft has removed many of the obstacles encountered
when creating distributed applications .
ADO uses a Recordset object that represents a table of data; however, this
view was not ideal for representing the often-relational data of today’s applica-
tions. In addition to this limitation, it has several options that confused many
developers learning the technology, such as cursor types, cursor location, and lock
types.These options generated a lot of confusion, especially if the user was not
familiar with the database from which the data was coming.
XML Support
XML is the native data format for ADO.NET. XML documents replace the
binary elements that were an integral part of ADO. XML is a standard with broad
www.syngress.com
Table 9.1
Continued
Namespace
Description
37
Using ADO.NET • Chapter 9
415
support and is ideal for the type of disconnected, distributed, Internet applications
being developed today. By leveraging XML, it is easier for developers of data
providers to integrate with ADO.NET. A data provider only has to create XML
documents to work with ADO.NET, which makes it a viable alternative for those
seeking the maximum flexibility for cross database development.
ADO.NET Configuration
Configuration for ADO.NET is handled during the .NET Framework installa-
tion.We don’t need to set any registry settings or path statements to alter. It all
happens on the fly, and all we have to do is understand it and use it.With ADO
we had to contend with MDAC updates until Windows 2000 came along and
incorporated this into the architecture. In some ways, we are back to the MDAC
days, except for .NET’s strategy to do away with dll.This also allows us to run
multiple versions of data access technologies without having to worry about
ramifications or breaking old code.Yes, even ADO.NET gets its roots from the
Common Language Runtime, along with all the benefits.
Remoting in ADO.NET
XML is key to remoting in ADO.NET. XML and HTML together can be used to
create services based on the Simple Object Access Protocol, or SOAP.This allows
us to create applications that operate similar to the Browser paradigm that has
made the Internet so diverse. By offering a service—for example, credit card
authorization—we can create a listener that understands a standard SOAP request
and after verifying a valid request can return a proper response.All this is possible
with XML. XML is at the center of ADO.NET, and therefore very important to
any .NET application that will involve data of any type.
Maintaining State
Since ADO.NET uses a connectionless, XML document methodology to handle
data access, maintaining state is not optional when using the DataSet object.When
we populate the DataSet, we are retrieving a populated XML document that is a
copy of the data stored in the original data source.This mandates that we have
“state,”and comes in handy when we have lengthy operations that may tie up a
connection. It also allows us to easily enhance our applications with a data cache
of often queried but seldom modified data.We can create a DataSet at application
startup and populate it with DataTables that we can use to populate drop-down
boxes and list boxes in our application without having to access the database each
www.syngress.com
35
416
Chapter 9 • Using ADO.NET
time the list needs populating.Add some code to refresh the cache after an
update, and we have an in-memory database that we can use to ease the burden
on the database server.This is just one example of a use for maintaining state in
an application.ADO.NET makes this type of development exceptionally easy.
Using the XML Schema Definition Tool
We can use the XSD Schema Definition tool to create schema files used for XML
data validation. In the Beta2 version, it is command line only. Entering XSD.EXE
/? at the command prompt brings up a long list of options for creating XML
schemas.To get a simple schema definition, consider the following MyData.xml
example (see CD file Chapter 09/Chapter9 Beta2/Samples/XML/MyData.xml):
<?xml version="1.0" standalone="yes"?>
<NewDataSet>
<Shippers>
<ShipperID>1</ShipperID>
<CompanyName>Speedy Express</CompanyName>
<Phone>(503) 555-9831</Phone>
</Shippers>
<Shippers>
<ShipperID>2</ShipperID>
<CompanyName>United Package</CompanyName>
<Phone>(503) 555-3199</Phone>
</Shippers>
<Shippers>
<ShipperID>3</ShipperID>
<CompanyName>Federal Shipping</CompanyName>
<Phone>(503) 555-9931</Phone>
</Shippers>
</NewDataSet>
Running the file through XSD.EXE results in this (see CD file Chapter 09/
Chapter9 Beta2/Samples/XML/MyData.xsd):
C:>xsd c:\MyData.xml
MyData.xsd
www.syngress.com
36
Using ADO.NET • Chapter 9
417
<?xml version="1.0" encoding="utf-8"?>
<xsd:schema id="NewDataSet" targetNamespace="" xmlns=""
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
<xsd:element name="NewDataSet" msdata:IsDataSet="true">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<xsd:element name="Shippers">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ShipperID" type="xsd:string" _
minOccurs="0" />
<xsd:element name="CompanyName" type="xsd:string" _
minOccurs="0" />
<xsd:element name="Phone" type="xsd:string"
minOccurs="0" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:schema>
To specify our new XSD as the schema of choice for our fresh new XML
Document, we simply add this attribute to our original root tag:
<NewDataSet xmlns="x-schema:MyData.xsd">
ADO.NET uses the xsd file to implement the Strongly Typed DataSet later in
the chapter.Visual Studio.NET uses the xsd.exe to create this file and then adds it
to the assembly.
Connected Layer
ADO.NET does not support connected data operations.You can, however, use
the older ADO and OLE DB libraries by converting them to .NET.This process
involves creating a .NET wrapper around the ADO libraries. Using this wrapper
www.syngress.com
Documents you may be interested
Documents you may be interested
