| 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. |
