Foreword

Pretty much every enterprise application uses databases. A large part of the code base of these applications is devoted to accessing and manipulating data stored in those databases. Accordingly, a large portion of the time and effort put into creating a new application is spent in the data-access space. That makes the data-access space a critical area that can be targeted by development tools to streamline the development process.

It's interesting to see how development tools change focus over time from one tier to another. Sometimes it's all about the presentation layer and how to make it really easy to build greatlooking desktop applications and Web browser based applications for use over the Web or the company intranet. Other times it's all about communications. Emphasis at still other times has been on data access and the data-access tier in general. The fact that the Internet has connected the whole world has changed the way we think about applications. Most recently a whole lot of new tools and technologies have been created to support our new environments.

When development tools and environments concentrated on data access in the past, they did it in different ways. For example, the folks who created languages and environments such as COBOL and xBase-like tools (among which are DBase and FoxPro) included data access as an intrinsic part of the infrastructure. These tools were created at different times and with different goals in mind but arose from many of the same ideas. You could declare the shapes of the records for the different entities in the system right in the language and use language primitives to scan, manipulate, and store those records.

Other tools used a different approach to the problem. Many data-access technologies were created around a programming interface instead of a language, making them usable from different languages at the cost of language integration. These APIs came in backend-specific flavors, such as Oracle's OCI or Sybase's CTLIB, or they came in backend-agnostic versions, such as the well-known ODBC.

We have our own cut of data-access history here at Microsoft. We've gone multiple ways: from DBLIB, a Microsoft SQL Server-specific API, to ODBC, an API designed to isolate developers from the backend specifics, to OLEDB, which aimed to enable "universal data access" over any data source out there, to ADO, a high-level API that simplifies the use of the powerful-but-complex OLEDB.

The evolution continues, and the expectation now is that you don't get separate support for any given task in isolation, be it data access, presentation, communications, or anything else that applications need to do. The software development community expects integrated application frameworks that address entire problem spaces.

In the Microsoft .NET Framework, data access happens through an API-based technology named ADO.NET. The entire .NET Framework is designed as a highly integrated and consistent set of classes. ADO.NET follows that design by providing classes for dealing with database connections, commands, and results in a way that fits nicely within the rest of the framework and within the Integrated Development Environment (the Visual Studio IDE).

ADO.NET is designed around a primary principle: simplicity. We wanted to make sure that every behavior exposed by the ADO.NET data-access framework is obvious and consistent. We made sure that you won't find surprises down the path because of some obscure limitation of the database or the data-access driver. In retrospect, I think that this concern for simplicity has helped make ADO.NET such a successful technology.

That very same clarity, however, brings some challenges to the table. By making everything explicit throughout the API, we ask our users to manually create and compose different elements of the API in a way that's appropriate for a given task. That requirement provides a lot of flexibility and avoids surprises for developers (because we don't do anything we weren't asked for), but also makes it harder to learn how to use ADO.NET.

To master ADO.NET, you need to learn the basics first. Many books and white papers describe ADO.NET, and MSDN publishes a lot of material that can help you get started with the technology. However, once you go through the initial steps, the real-world issues and requirements start to show up. What are the characteristics of the "connected" and "disconnected" patterns? How do you make sure your application is secure? What's the best way of leveraging the internal workings of connection management to maximize application performance?

I love the book you're holding in your hands because it tackles those issues, the hard ones that come up when you're solving real problems. When you're writing an application, you'll run into most if not all of these issues, and I find this book to be the right reference to review to make sure you leave no loose ends in the work you do.

Pablo Castro
ADO.NET Technical Lead
Microsoft Corporation