6. Accessing Data: ADO.NET

< BACK  NEXT >

[oR]

Chapter 6. Accessing Data: ADO.NET

Working with data searching, updating, and processing it is one of the fundamental tasks of software. Today, much of that data is commonly stored in some kind of database management system (DBMS), usually a relational DBMS. Developers need some mechanism that allows their applications to access this information. In Windows DNA, a group of COM classes called ActiveX Data Objects (ADO) solves this problem. In the .NET Framework, the solution is a radically updated version of ADO called ADO.NET.

ADO.NET provides access to stored data

Like everything else in the .NET Framework class library, ADO.NET is nothing more than a group of types, all of which reside in the System.Data namespace. These types are used by client applications that need to work with stored data, and they allow access to that data in various useful ways. As before, the most common need is to work with relational data, such as tables stored in Oracle or SQL Server, and so much of ADO.NET focuses here. Yet as described in Chapter 5, data defined using XML gets more important every day. Recognizing this, ADO.NET's creators also added support for working with XML documents. This chapter takes a look at what ADO.NET provides for applications built on the .NET Framework.

ADO.NET allows access to both relational and XML-defined data

Oh, No, Not Another Data Access Interface!

ODBC, OLE DB, ADO: The list goes on and on. If you've been working in the Microsoft world for a while, you've surely encountered some of these access technologies (and perhaps others this is not a complete list). Each of them was at one time presented as the optimal way to access data, especially data in a relational database system. Yet today, each of them is a legacy technology, which means that while new applications shouldn't in general use them, somebody still has to support the old applications that do use them.

Why does Microsoft do this? Why can't the people in Redmond make up their minds in this terrifically important area? After all, the dominant database model hasn't changed in 20 years a relation today is pretty much the same as it was then so why should the way we access relational data be so volatile?

There are many answers. For one thing, the interface between object-oriented software and relational databases is inherently a messy place. With few exceptions, the database people never bought into objects as a core abstraction. There are good reasons for this objects work much better for creating software than they do for storing data but the result is a mismatch of models and a plethora of pain. In its attempts to make this difficult interface as useful as possible, Microsoft has taken a few wrong turns.

A more obvious reason for creating a new data access interface is that ADO, the currently dominant choice, is based on COM, while the .NET Framework is not. .NET Framework applications can use ADO through the Framework's COM interoperability features, but doing this is relatively slow. It makes more sense to offer a data access mechanism built solely with managed code, which is exactly what ADO.NET provides.

Another reason for the instability in data access interfaces is that the problem being addressed changes regularly. A primary goal of ODBC was to let applications written in C and C++ issue SQL queries against a database system. These applications were either running on just one system or were spread across two machines in a two-tier client/server configuration. Yet today the most common scenario is a browser talking to business logic on a middle-tier server. In this kind of application, it's this middle-tier logic that accesses data and then passes it across a network to the browser. ODBC didn't address this situation at all, since it provided no way to serialize its results for transmission across a network. ADO addressed it in a way that made some sense inside the firewall but didn't work well on the Internet, especially with browsers other than Internet Explorer. ADO.NET, however, was designed with exactly this style of application in mind. And because the older models are still the right approach for some applications, ADO.NET also allows writing code in a more traditional style.

Finally, new people join development teams at Microsoft all the time, and the existing people move on to other groups or other companies (or they retire at 30, although this looks like less of an issue in these post-bubble years). New people bring new ideas, and as ownership of a technology changes, that technology will also change. I don't believe Microsoft is intentionally making developer's lives difficult, but that has sometimes been the result of the technology churn in data access interfaces. Still, ADO.NET is a clean, attractive, and relatively simple technology for today's applications. All historical confusion aside, it's a good fit for the world of the .NET Framework.

< BACK  NEXT >