Chapter 11. Accessing Data with ADO.NET

So far in this book, we've used an ArrayList as the data source for data-bound controls. In most real-world applications, of course, the data source will be a database. ADO.NET provides a rich set of objects to manage database interaction.

ADO.NET looks, at first glance, very similar to ADO, its predecessor technology. The key difference, however, is that ADO.NET is modeled around a disconnected data architecture. Database connections are "expensive" (that is, they use a lot of resources), and it is difficult to have thousands (or tens of thousands) of simultaneous continuous connections. A disconnected architecture, on the other hand, is resource-frugal. Connections are used only briefly. Of course, ADO.NET does connect to the database to retrieve data, and connects again to update data when you've made changes. When not updating data to or from the database, the connection is broken. Most web applications spend most of their time simply reading through data and displaying it, and ADO.NET provides a disconnected subset of the data for your use while reading and displaying.

As you might imagine, disconnected datasets can have scale and performance problems of their own. There is overhead in creating and tearing down connections, and if you drop the connection each time you fill the database, and then must reestablish it each time you update the data, you will find that performance begins to degrade quickly. This problem is mitigated by the use of connection pooling. While it looks to your application like you are creating and destroying connections, you are actually borrowing and returning connections from a pool that ADO.NET manages on your behalf.