Web Service Optimization

Chapter 10

Exposing Data to .NET Applications

The ADO.NET framework is made of two distinct groups of constituent classes: the generic container classes and the data source-aware classes. The data source-aware classes are still part of the System.Data namespace but are tightly integrated with a specific data source. Although data source-aware classes provide general-purpose functionality, their implementation is based on the features of a particular data source. So ADO.NET command classes, for example, might have a different set of methods depending on whether they work against an OLE DB provider or Microsoft SQL Server.

The container group of ADO.NET classes are abstracted from the physical data source. Although they represent data tables, rows, columns, and primary keys, nothing in their programming interface keeps track of the content source. Thus, a DataTable object or a DataSet object can be filled with data retrieved from a commercial database server as well as filled with packets of data read from a connected device.

The point of contact between data source-aware classes and container classes is represented by a new breed of component: the .NET data provider. Such managed data providers in .NET play the same role as OLE DB providers in the COM world. In the past few years, companies invested a lot of money in the OLE DB technology. OLE DB turned the vision of a universal data access strategy, theorized in the Universal Data Access (UDA) specification, into concrete programming calls. OLE DB is built on the idea of using a suite of COM interfaces to read and write the contents of data sources irrespective of their relational, hierarchical, or flat architecture.

Maybe the C++ oriented design that OLE DB came up with is a bit too complex for widespread use, but it definitely provides great flexibility when exposing proprietary data in a standardized way. OLE DB supplies a common COM-based API that enables consumer applications to talk to data provider modules without knowing about internal details. Each provider encapsulates a particular data store such as a commercial database, a system component such as Active Directory, or, more simply, the manager of proprietary data with a custom format. According to the UDA specification, OLE DB is the tool of choice to universalize data access.

The advent of .NET pushed all COM-based technologies to the side, and OLE DB was no exception. All .NET applications that want to access data by using OLE DB providers must bust out of the common language runtime environment and rely on COM interoperability and enterprise services. Such a move creates overhead that of course never benefits overall application performance. To ameliorate these issues, which are at the core of data access, .NET introduced managed data providers. Managed data providers are patterned after OLE DB providers but also access data within the context of the common language runtime in a simpler and more effective way.

In the pre-.NET era, OLE DB providers were your primary option for making your proprietary data publicly available that is, available in a widely accepted format. For relatively simple data formats (such as comma-separated files), you also had the option of using the OLE DB Simple Provider Toolkit. The Simple Provider Toolkit provides tools for writing (even in Microsoft Visual Basic) shrink-wrapped OLE DB providers with limited functionality. In .NET, exposing proprietary data requires a more sophisticated approach, and you have multiple and equally powerful options from which to choose.