Summary
In this chapter, we have expanded on the data
source control and data display control discussions of Chapters 3
and 4. We started by looking at some of the simple uses for the
events of the data source controls, such as rebinding other display
controls on the page and how to modify the parameters before a
SelectCommand
is executed.
We then moved on to output parameters and how to
access values sent back from executed commands, such as the
identity value of a newly inserted row. You saw that from within
the event procedure, the way of accessing output parameters is the
same whether using a
SqlDataSource
or
ObjectDataSource
control.
We then moved on to the
ObjectDataSource
using a strongly typed business class,
and we showed how to implement custom paging so that the display
controls can provide the same functionality that the
SqlDataSource
provides. The paging revolves around your
business class supporting the use of the number of rows in a page
and which row to start on, as well as knowing the total number of
rows.
We then
briefly
saw an overview of the events
for the
GridView
and
DetailsView
before moving
into conflict detection and concurrency errors, detailing how to
avoid the lost update problem. This section showed that events for
the display controls are much more useful than the events on the
data source controls, because the display control events provide
access to all versions of the data being updated.
The second half of the chapter
looked
at one
particular aspect of SQL Server CLR Integration, which is the use
of custom types in database. We showed how to created a
User-Defined Type to store mapping information, and then how that
custom type can be used in client applications. You can see that
this provides a simple way to create some exciting applications
without having to worry about handling complex data, because the
database and the UDT handle the data natively.
Now it's time to move into how to improve the
performance of applications, so we'll take a look at caching.
|
