asp.net 2.0: best data structure to bind to gridview

Question

For the most part, the application I'm working on deals with object, and I can bind a list of objects to a gridview without any problems.

However, in a couple of cases, I want to display the results of a multi-table join in a gridview. The current code uses a dataset, which is pretty easy, but I'm wondering if there's a better/more efficient way to do this.

We don't need most of the features of the dataset - data is read-only, and there will not be a large number of records in most cases. (i.e. probably no more than 200, and usually 10-20)

Answer 1

I think you should be using the DataReader whenever possible. There are times when a DataSet is more appropriate, such as the two situations listed below. These came from the article, "Why I Don't Use DataSets in My ASP.NET Applications". Also check out the follow up article, "More On Why I Don't Use DataSets in My ASP.NET Applications".

1. In a desktop, WinForms application. Consider a desktop-based data entry-type program. A user might fire up the program, load up the sales data from some database server, make some changes, and then want to save those changes. This is an ideal situation for the DataSet. It allows the data to be read into a DataSet residing in the client's memory, which affords the user the ability to work on the data without needing to constantly make trips back to the database. Upon completing editing the data, they can do a batch update, gracefully handling any changes that may have occurred while the user was working with the data in a disconnected state. Furthermore, since the DataSet is a disconnected data store, this data can be taken offline. A salesman traveling to a client's site could load this data and be able to review the data on his laptop while in transit, or while at the client's office.

2. For sending/receiving remote database information or for allowing communication between disparate platforms. Since a DataSet can be serialized/deserialized into XML so easily, they are a prime candidate for sending information across physical boundaries or as a means of serializing data into a platform-neutral format. For example, if you want to return database data from a Web service, one option is to simply read the database data into a DataSet and then return the DataSet from the Web service method. The DataSet will automatically be serialized into XML and sent over the wire. (Personally I don't recommend returning data from a Web service in this manner. Rather, I prefer to use custom business objects - it allows a finer degree of control over the XML serialization, provides a much lighter return payload, and appears less architecture-specific.