Datasheet

Chapter 1
20
The data adapter object represents a set of commands and a database connection, providing an
alternative method of retrieving data. It provides support for the data to be updated as well as
just read, so in some ways it can be seen as a big brother to the data reader. Even so, the data
adapter does not allow for direct editing of the data source; rather, it fills a dataset with a copy
of information from the data source, and can then be used to write any changes to the data
back to the database.
The dataset can be thought of as a local copy of a portion of the data store. In this copy, rows
of data can be read, added, edited, and deleted. Because the data is cached locally, it can be
read in a random manner, as opposed to the forward-only manner of the data reader. When
the required changes have been made to the data, they can be sent back to the data store
through the data adapter. Until this point, the dataset is disconnected from the data store.
Looking to the far right of the diagram, you can see two unattached lines – this is where the 'front end'
of your application connects to the ADO.NET architecture. The data that is returned here can be used
in any way the developer chooses – displaying it to a web page, writing it out to a file, etc.
The twin concepts of "connected" and "disconnected" data are important ones, and while we've barely
touched on them here, we'll be developing these ideas in later chapters – Chapters 4 and 5 in particular.
Data Providers
One of the key features of ADO.NET is that it's optimized for the various possible types of data store.
Apart from the dataset, which is generic, the other objects in the above list have versions that are
specifically geared towards accessing data of a particular type. For example, there are separate data
reader classes for dealing with SQL Server and Microsoft Access databases. The umbrella term given to
the 'set' of classes that deals with a particular type of data store is a .NET data provider.
As discussed, a data provider is a package of classes that implements a set of functionality allowing
access to a specific type of data store. While there's a base set of functionality that a data provider must
supply in order to be called as such, a particular data provider can have any number of extra properties
and methods that are unique to the type of data store that is being accessed. This is very different from
ADO, where there was a single set of classes that was used for accessing dissimilar data sources.
Where do Data Providers Fit in the Scheme of Things?
At this point, you're probably starting to think that you're getting a feel for the basic architecture of
.NET, and that you can see why data providers allow for more types of data store to be accessed, but
you don't know how the two relate to each other. Earlier on, we had a diagram of the technologies that
were involved in data access before the introduction of ADO.NET. The following diagram shows how
this changes – and how it gets simpler – under ADO.NET.