The Role of ADO.NET in a Distributed System

ADO.NET is a critical piece of almost any enterprise application simply because most applications need to access a database at some point. In this case, using the legacy ADO libraries makes little sense. They reduce performance (because execution must travel between your managed .NET code and the unmanaged ADO objects through a COM interop bridge) and add few useful features.

ADO.NET supports more than one model of data access. First of all, it uses a simple connection-based paradigm that enables you to execute individual commands. You'll find that this is the most useful aspect of ADO.NET for designing database components using the "service provider" design pattern introduced in Chapter 2. ADO.NET also provides disconnected data access, which is a quick-and-easy way to send information between tiers. In this case, the DataSet essentially takes the role of the "information package" component. It's an enticing option, but it strips away a layer of indirection (the custom information package class), potentially making your solution less generic and making it more difficult to update the client in response to data source changes.

Finally, ADO.NET can play a special role in a system that incorporates non-.NET clients. Internally, the DataSet stores information in a binary form optimized for XML output. That means you can look at the DataSet as an XML document without the danger of losing information. Clients in other programming languages won't know how to manipulate a DataSet object, but they can usually parse an XML document and schema, which makes it easy to transfer information around without needing to write your own error-prone conversion code. You'll read about this possibility at the end of this chapter.