Page 100 - DCAP312_WEB_TECHNOLOGIES_II

Web Technologies-II

Notes 5. The data set is similar to an array of disconnected Record set objects.
(a) True (b) False

5.4 DataAdapter

The ADO.NET DataAdapter and serialisable DataTable are the pivot pins of ADO.NET have
disengaged structural design. These classes provide a way to depiction one or more rowsets and
an instrument to update the information. This is a new mechanism for data access developer’s
inscription code for all application architectures.

Note that the DataAdapter is implemented by each of the .NET Data Providers incorporated in the
Windows .NET Framework. For example, in the SqlClient .NET Data supplier, the DataAdapter
is implemented as the System.Data.SqlClient.SqlDataAdapter. The DataAdapter is not really
a new idea born with ADO.NET. Its roots come not from Tao, but from the DOW – the Data
Object Wizard first introduced in Visual Basic 6.0 but henceforth abandoned in light of the
innovations in Visual Studio.NET. The DOW was used to generate a class that fetches a rowset
and defines the UPDATE, DELETE and INSERT SQL needed to manage the rowset. Basically,
the Visual Basic.NET DataAdapter does the same thing. Unlike the Data Object Wizard, the
DataAdapter permits you to define both the input and action queries with a few more options.
It also sports a facility to automatically generate the action queries – but regrettably, only for
"home" database challenges.

One of the most significant differences between COM-based ADO "classic" (ADOc) and ADO.
NET is how updates are handled. In ADOc, action SQL was generated on the fly controlled
by the Update Criteria and other properties. It did not require an extra round trip to generate
this SQL, but it did require a bulkier SELECT FOR BROWSE to return schema information
needed to construct these action commands. ADO.NET takes another approach – it leaves the
generation of the update commands up to the developer. This means that developers have far
more flexibility in how updates are posted to the data.

One of the most significant differences between COM-based ADO “classic” (ADOc) and ADO.
NET is how updates are handled. In ADOc, action SQL was generated on the fly controlled
by the Update Criteria and other properties. It did not require an extra round trip to generate
this SQL, but it did require a bulkier SELECT FOR BROWSE to return schema information
needed to construct these action commands. ADO.NET takes another approach – it leaves the
generation of the update commands up to the developer. This means that developers have far
more flexibility in how updates are posted to the data.
5.4.1 Choosing between the DataAdapter and the DataReader

When you first start working with the ADO.NET DataAdapter, you might be puzzled as to how
to best use it with existing data access architectures. Developers, yearning for better performance,
often lean toward the low-level DataReader approach – rolling their own update code or using
the Command methods to execute stored procedures which update the source tables. They are
not convinced that the extra features exposed by the DataAdapter and its associated DataSet
and DataTable are worth the extra CPU cycles. In addition, once the DataTable is created, the
additional functionality exposed by its methods and properties further simplify and stabilise
the code – without further loss in the developers or the code’s performance.
5.4.2 Getting the Best Performance from the DataAdapter

The disconnected architecture implemented by ADO.NET assumes that your code returns a
set of rows to the client and posts changes to the in-memory copy of the data. These changes
are not reflected in the database until you submit a “batch” of updates using the DataAdapter

94 LOVELY PROFESSIONAL UNIVERSITY