|
The Disconnected Objects
Disconnected applications
typically connect as late as possible and disconnect as early as they can.
While they are working in a disconnected fashion, ADO.NET pools the actual
physical connection between various requests.
The various objects in
consideration under the disconnected model of ADO.NET are as follows:
DataSet: The DataSet is at the
central core of the disconnected mode of ADO.NET data access. The best way to
think of a DataSet is like having your own very mini relational database
management system (RDBMS) completely represented in memory. While it isn’t
quite an RDBMS and should never be thought to replace an RDBMS, it helps to
understand a DataSet if its various components are connected on a one-to-one
basis with most major RDBMS objects. Also, it is important to realize that
DataSets are available at System.Data.DataSet, i.e., above any .NET provider,
thus making them .NET data provider–independent (more about .NET data providers
in the next section). A DataSet can also be thought of as a logical collection
of DataTables and DataRelations.
DataTable: A DataTable is most
similar to a table in a database. It consists of DataColumns, DataRows, and various
constraints set upon them. It stores data in a row/column format. Starting with
ADO.NET 2.0, a DataTable is fully convertible to XML and can be serialized just
like a DataSet. For data access needs where your DataSet might contain only one
DataTable, it may make more sense to use a DataTable instead. As you’ll see in
future chapters, this is not only more convenient, but it’s also better
performing.
DataRow: One of the properties of
DataTable is Rows of DataRowCollection type, which represents an enumerable
collection of DataRow objects. As data is filled into a DataTable, the
DataRowCollection gets new DataRow objects added to itself. The best logical
equivalent of a DataRow in a database is a row in a table.
DataColumn: A DataTable also contains
a Columns property of DataColumnCollection type. Essentially, this represents
the structure of a DataTable. The best logical equivalent of a DataColumn
object in a database is an individual column in a given table in a database.
DataView: A DataView is most
similar to a view in a database. A DataView allows you to create a “view” on a
DataTable and view a subset of the data based on a preset condition specified
in its Filter property. You could also use the Sort property to sort the
filtered subset of the DataTable’s data. One
DataTable can have multiple views defined on it.
Constraint: A DataTable contains yet
another property called Constraints of ConstraintsCollection type. This lets
you create ForeignKeyConstraint or UniqueConstraint objects and associate
various columns to certain conditions based on which data in the DataTable must
pass for it to exist in the DataTable. The most logical equivalent of a
ForeignKeyConstraint is a foreign key in a database, and UniqueConstraint
specifies a Unique condition on a given column in a database. DataRelation: A DataSet,
like a database, might contain various interrelated tables. A DataRelation
object lets you specify relations between various tables that allow you to both
validate data across tables and browse parent and child rows in various DataTables.
Its most logical equivalent is a foreign key specified between two tables in a
database. The difference between a ForeignKeyConstraint and a DataRelation is
that a DataRelation, in addition to validating data, gives you a convenient
mechanism to browse parent and child rows in a DataSet.
Figure below shows where the various
connected and disconnected objects fit into the bigger picture. 
When compared with ADO, the data
holder object, which used to be Recordset, is now a DataSet. However, there is
a critical difference. While a Recordset was also responsible for communicating
with the database, a DataSet is not responsible for communicating with the
database. Instead, it uses the gateway object between connected and
disconnected modes—the DataAdapter.
|