|
|
Architecture is everything. It affects how entities are designed, how they work, and, ultimately, it defines what we can do with them. ADO and ADO .NET have two completely different architectures. This section of the chapter touches on the fundamental principles behind the two technologies and how they differ.
Turn the pages of your history book. Microsoft released ADO as part of its Universal Data Access (UDA) strategy. OLE DB was also released as part of UDA and was originally the standard that developers would use to access and manipulate data sources. Contrary to the ODBC standard that was tied to Windows, OLE DB brought some world peace to the data access industry by allowing database engine developers to implement providers that would essentially provide OLE DB interfaces to data sources. A key example is the Microsoft SQL Server database engine. SQL Server data sources are stored on a database server. The SQLOLE DB provider provides all the means of communication that any client or other servers need with that particular data source. An OLE DB provider may even allow developers to use customized query languages in querying the data sources. In the case of SQLOLE DB, that language is called T-SQL.
To implement an OLE DB provider, one would use the OLE DB API. This is a set of low-level functions written in the C language. With the implementation of such an open architecture, Microsoft was clearly targeting the big database vendors, such as Oracle, Informix, and Sybase, while creating unified data access architecture for its flagship operating system—Windows.
To facilitate rapid development of database applications and further expand its COM (Component Object Modeling) standard, Microsoft released ADO as a library of rich COM components providing high-level interfaces that would sit one layer above the very hard-to-use OLE DB API. Using ADO, database developers would simply attempt a connection to a data source, query the data source, and load a set of rows (record set) into memory.
The .NET Framework does provide support for ADO. In fact, it is possible to create a fully functional ADO application that runs on the .NET Framework. However, if you intend to create an ADO application, I suggest that you stick to Visual Studio 6 because there are a lot of architectural issues that you will face.
As mentioned above, the ADO architecture is based on the principles of COM. The .NET Framework does not support COM directly, but rather, it has a COM interoperability class library that sleeps silently within the COMLIB namespace. When using COM in .NET applications, the CLR always sends requests to the COM interoperability layer whenever you reference anything that is based on COM. This is always the case when you reference ADO objects in a .NET application. It has an enormous negative impact on the speed at which such an application runs. There is no need to pay such a high cost when you have the ADO .NET class library to use that is directly executable by the CLR.
Secondly, there is an issue with the famous ADO Recordset object. This object is used to retrieve and store data in memory. It has a property of the COM type variant called Fields. The .NET CLR does not support the variant data type, as is the case with several other COM data types. Whenever ADO is used in the .NET application, there are a series of data type conversions that the CLR needs to do through the COM interoperability library. This again puts a huge burden on the application’s performance.
For a list of COM data types found in ADO and their corresponding .NET data types, refer to the table below:
|
ADO Data Type |
.NET Framework Data Type |
|---|---|
|
adEmpty |
null |
|
adBoolean |
Int16 |
|
adTinyInt |
SByte |
|
adSmallInt |
Int16 |
|
adInteger |
Int32 |
|
adBigInt |
Int64 |
|
adUnsignedTinyInt |
Int16 |
|
adUnsignedSmallInt |
Int32 |
|
adUnsignedInt |
Int64 |
|
adUnsignedBigInt |
Decimal |
|
adSingle |
Single |
|
adDouble |
Double |
|
adCurrency |
Decimal |
|
adDecimal |
Decimal |
|
adNumeric |
Decimal |
|
adDate |
DateTime |
|
adDBDate |
DateTime |
|
adDBTime |
DateTime |
|
adDBTimeStamp |
DateTime |
|
adFileTime |
DateTime |
|
adGUID |
GUID |
|
adError |
ExternalException |
|
adIUnknown |
Object |
|
adIDispatch |
Object |
|
adVariant |
Object |
|
adPropVariant |
Object |
|
adBinary |
byte |
|
adChar |
string |
|
adWChar |
string |
|
adBSTR |
string |
|
adChapter |
not supported by .NET |
|
adUserDefined |
not supported by .NET |
|
adVarNumeric |
not supported by .NET |
Third, there are also the design goals of the .NET Framework to consider. .NET was designed so that application services could talk to each other using technologies such as XML and remoting. ADO does not support XML, nor does it allow disconnected data sharing between remote application servers. Using ADO in .NET applications limits the amount of things that you can do to implement a true .NET application.
A great part of the .NET Framework is called .NET class libraries. These libraries contain a set of classes that provide services that developers use to create .NET applications. Among these libraries is the System.Data class library.
System.Data holds all the functionality needed for developers to create rich, scalable, and distributed database applications that run on the .NET Common Language Runtime. System.Data provides a unified, object-oriented, hierarchical, and extensible set of classes. It is a common API that is usable across all .NET programming languages, while the CLR enables cross-language inheritance, error handling, and debugging of data classes. Together, the functionality present in these classes is referred to as ADO .NET, and this is what we will discuss throughout the rest of this book.
There are three main design goals behind ADO .NET:
To provide seamless support for XML
To provide an expandable and scalable data access architecture for the revolutionary n-tier programming model
To extend the current capabilities of ADO
The core ADO .NET architecture is built to provide access to relational, XML, and other OLE DB data sources. The XML-centric classes are not within the System.Data library; they are part of the System.XML library. Therefore, it is important to reference both the System.Data and System.XML namespaces in any database applications that you create. In contrast to the ADO object model, ADO .NET separates data access from data manipulation, therefore enabling flexibility when operating in a disconnected environment.
In a typical data manipulation scenario, data is retrieved using the DataReader object through a .NET data provider. The retrieved data can be processed directly or, alternatively, it can be stored inside a DataSet object on the client. Within the DataSet, the data is completely separated from its source. The DataSet provides the developer with three powerful and flexible aspects:
Data within the DataSet object can be manipulated and exposed to the user in several ways using other objects like DataTable, DataRelation, and DataViews contained within that DataSet.
The content of a DataSet can be combined with data from other data sources. This offers the developer the superb capability to unify several types of data. Think of a scenario where you may have to implement a link between your Sales, CRM, and Accounting systems. Traditionally, this would have been done using classical COM interfaces. The ADO .NET DataSet hides all these complexities by providing seamless data integration capability.
The DataSet provides the ability for you to share data among remote tiers of an application or application servers. Although many developers prefer to share data using XML, this is an excellent way to share data between tiers in the n-tier application programming model.
More is written about the DataSet object in Chapter 3, “Data Manipulation.”
In a typical .NET database application, objects and data-sharing services, referred to as consumers, interact with the database using a .NET data provider. To further isolate data access from data manipulation, a provider is implemented to act as a form of interface between data consumers and data servers. It holds all the logic required to perform, retrieve, and update operations on a data source. The provider would be used to retrieve data into a DataSet and update the database.
ADO .NET ships with two data providers: the SQL Server .NET Data Provider and the OLE DB .NET Data Provider.
| Note |
Other independent database vendors such as Oracle, Informix, and Sybase, may implement data providers for their own data sources. |
The SQL Server .NET Data Provider is the provider used for SQL Server databases implemented in SQL Server 7 or later. Data access to OLE DB compliant data sources is achieved using the OLE DB .NET Data Provider.
The remainder of this chapter covers the differences between ADO and ADO .NET.
|
|