Chapter 3. Disconnected Data: The Universal Language

I've often described the Microsoft .NET Framework as a collection of several not-so-minor revolutions bundled into a single platform, and data access is no exception. ActiveX Data Objects (ADO), Microsoft's previous COM-based data access technology, has been redesigned and rebuilt in the form of ADO.NET. And although ADO.NET bears some superficial similarities to ADO, it shifts the focus to distributed applications and the scalability considerations they entail. That isn't to say that you can't create a distributed application that connects to a database using ADO technology in fact, with proper design practices, ADO still works like a charm. The problem is that many developers either ignored or forgot those best practices and created clumsy resource-intensive applications. ADO.NET is quite a bit more restrictive than ADO it's designed to make these bad habits almost impossible.

ADO.NET isn't just a more restrictive version of ADO (although a skeptical programmer might make that claim). ADO.NET adds features that make it easier to send data to remote components, serialize it to XML, and make it available to software written in other languages. These features are all wrapped up in a special object called DataSet, which is an enriched data container that tracks changes and is optimized for translating data into XML. The features of the DataSet are far beyond ADO's primitive Recordset and include support for multiple tables, table relations, and column constraints. But the truth of the matter is that the DataSet is rarely used for updating data in an enterprise application. There are several reasons for this design pattern (all of which we'll explore in this chapter), but the dominant reason is that DataSet programming is complicated in an enterprise environment, where you must write additional code to handle the inevitable concurrency and stale data errors. Unfortunately, many beginning ADO.NET programmers fail to protect against these potential problems and don't realize the vulnerability of their code until it is deployed in a production environment. In most business applications, the additional details required to use disconnected batch updates are rarely worth the coding headaches. On the other hand, the DataSet is often an ideal one-way data transport, allowing data to be downloaded to a client in a single convenient package.

In this chapter, we'll focus on questions about how you should use ADO.NET and the DataSet in an enterprise application. I won't explain the entire ADO.NET model (because there are entire books on that subject). Instead, I'll identify the best ways to use the features of ADO.NET in a distributed system.