C# 4 and .NET 4

856 ❘ ChaPTer 30 cOre AdO.net
One of the difficulties with this model is deciding what data to transport between your tiers as well as
figuring out the format in which the data should be transported. With ADO.NET, you will be pleased to
learn that these wrinkles have been ironed out, and support for this style of architecture is part of
the design.
One of the things that is much better in ADO.NET than OLE DB is the support for copying an entire record
set. In .NET, it is easy to copy a DataSet:
DataSet source = {some dataset};
DataSet dest = source.Copy();
This creates an exact copy of the source DataSet — each DataTable, DataColumn, DataRow, and Relation
will be copied, and all data will be in exactly the same state as it was in the source. If all you want to copy is
the schema of the DataSet, you can use the following code:
DataSet source = {some dataset};
DataSet dest = source.Clone();
This again copies all tables, relations, and so on. However, each copied DataTable will be empty. This
process really could not be more straightforward.
A common requirement when writing a tiered system, whether based on a Windows client application or
the Web, is to be able to ship as little data as possible between tiers. This reduces the amount of resources
consumed.
To cope with this requirement, the DataSet class has the GetChanges() method. This simple method
performs a huge amount of work, and returns a DataSet with only the changed rows from the source
data set. This is ideal for passing data between tiers because only a minimal set of data has to be
passed along.
The following example shows how to generate a “changes” DataSet:
DataSet source = {some dataset};
DataSet dest = source.GetChanges();
Again, this is trivial. Under the hood, things are a little more interesting. There are two overloads of
the GetChanges() method. One overload takes a value of the DataRowState enumeration, and returns
only rows that correspond to that state (or states). GetChanges() simply calls GetChanges(Deleted |
Modified | Added), and first checks to ensure that there are some changes by calling HasChanges(). If no
changes have been made, null is returned to the caller immediately.
The next operation is to clone the current DataSet. Once this is done, the new DataSet is set up to ignore
constraint violations (EnforceConstraints = false), and then each changed row for every table is copied
into the new DataSet.
When you have a DataSet that just contains changes, you can then move these off to the data services tier
for processing. After the data has been updated in the database, the “changes” DataSet can be returned
to the caller (for example, there might be some output parameters from the stored procedures that have
updated values in the columns). These changes can then be merged into the original DataSet using the
Merge() method. Figure 30-9 depicts this sequence of operations.
Client Tier
Data Services Tier
Database Tier
Changes
Update
DataSet
Merge
DataSet
New Data
figure 30-9
www.it-ebooks.info