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.