Summary

We covered a lot of material in this chapter. That was necessary because the objects and concepts discussed here (together with those in Chapter 4) form the basis of all the database applications that we will develop with ADO.NET and Visual Basic.NET. We have shown how the DataSet and its associated objects, such as the DataTable, DataRelation, DataRow, and DataColumn, provide great flexibility and a rich programming model for handling data while disconnected from the physical data source. In Chapter 6, we demonstrate how the DataAdapter can be used to fill the DataSet with data and to provide automatic updating to the data source of the changes made to the DataSet.

Questions and Answers

Q1:

I understand that I can still access my data source data either directly (using data commands) or indirectly (using disconnected). Are there any guidelines as to which approach is better for different scenarios?

A1:

Using DataSets has several advantages over direct database access. It provides a simple and uniform way to move data between the different tiers and locations of a distributed database application, as well as between different applications, owing to its inherent XML support. It provides a mechanism for data caching and allows you to sort, filter, and search these data without having to access the data source for each operation. Finally, it allows you to fetch multiple tables, possibly from different data sources, and to manipulate them either individually or based on the relationships between them. Directly accessing the data source by using the Command object has its own advantages. Some operations, such as those that modify database structure, can be performed only by direct access. Even for standard SQL statements or stored procedure calls, direct commands provide more control over the timing or method of execution of the commands, which may facilitate greater performance or scalability. Finally, the overhead of the memory requirements of the DataSet can be reduced, especially when there is no application-driven need to cache the data, such as when you're building a Web page or populating a listbox. So when should you use direct database access rather than DataSets? Clearly, if you are performing an operation that can be done only through a Command object, that is the way to go. This situation includes calling stored procedures that perform manipulations and return only a return value and/or parameter values, as well as database structure or DDL operations. You also should avoid using DataSets (1) if the data is read-only; (2) if your use of it is to be short-lived and loading and retaining the DataSet in memory doesn't pay; or (3) if the data is to be used on the server and there is no need to pass the data to a different tier or computer. In most other cases, it is usually best to use and take advantage of the flexibility of ADO.NET's DataSet object.