|
|
 |
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Published: Wednesday, May 18, 2005 By Scott Mitchell
Introduction
DataTables vs. DataSets I mostly use DataTables (sometimes DataReader) since pages usually deal with a single table of data. It is quite upsetting to find books and tutorials forever teaching the use of DataSet together with DataAdapter. I wonder how many know the DataAdapter works with DataTables stand alone.Yes, it is true that the DataTable is more efficient than the DataSet. The DataSet is, after all, a set of DataTables; you can programmatically access the DataSet's collection of DataTables through its Tables property. And DataTables offer
the functionality not found in DataReaders: DataTables support random access, can be sorted and filtered using DataViews, their
contents can modified through insertions, updates, and deletes.
So should you use DataTables in lieu of DataSets? Sure, if you can. A DataTable doesn't support all of the features of a DataSet, so they might not be an appropriate choice. (For example, in .NET 1.x DataTables cannot be natively serialized into XML; additionally, if you need to represent relationships among multiple DataTables, you'll need to use a DataSet.) What it all comes back - and this was my thesis from the original Why I Don't Use DataSets article - is that you should use the right object for the job at hand. Each data object has a time and place - my contention is that DataSets (and DataTables) have limited use in ASP.NET applications.
Returning DataSets from Web Services If you're using webservices in your application that return result sets, then you would want to use a dataset to hold these result sets.While DataSets are an easy way to return data, I think they are less than ideal for a couple of reasons. First, they add a lot of bloat to the returned XML payload since DataSets return not only the data they contain but also the data's schema. If you are only returning a small number of records, the payload's size can be dominated by the schema information. Second, DataSets have the air of being platform specific. While it's true that an XML serialized DataSet is, after all, just XML and therefore can be processed by a client on any platform, it still has a platform-specific feel to it since the resulting XML markup is dictated by Microsoft. A .NET client can automatically deserialize a DataSet's XML payload returned from a Web service back into a DataSet, thereby making DataSets an easy and attractive option. Clients using other platforms, however, will find they have to invest a lot more effort in order to work with the server's returned serialized DataSet. The solution? Create a serializable, custom business object and have your Web services return an array of these custom objects. The overall payload size will be significantly less and the returned payload will be more inviting to clients not using .NET. One commenter summed up this sentiment nicely with: For me, DataSets are too platform specific to use in Web Services. I prefer returning XML serialized arrays of objects. It may require my consumer to do a little bit more work, but it ensures that I have a wider base of consumers.The one downside of returning custom collections from a Web service is that for .NET clients, these custom classes are serialized as classes with public fields as opposed to public properties. When binding a custom collection to a DataGrid or other data Web control, the data binding only allows binding to properties. Fortunately this nuisance is fixed in .NET 2.0. (For more information on the benefits of returning custom collections from Web services as well as how to work around the field/properties pain, be sure to check out the "Binding to Web Services" section of Dino Esposito's Collections and Data Binding article.)
Yes, Using DataReaders You Can Do That, Too!
Additionally, in reading many of the comments in favor of DataSets it appeared that a number of commenters seemed to think
that the DataSet was an ideal object for computing aggregates - counts, sums, and so on - or for retrieving two related tables
and displaying fields from both. While the DataSet can accomplish these tasks, I'd recommend performing these operations at
the database if possible. SQL has a rich set of aggregate functions -
How Important is Performance? This gives rise to the question, then, of "How often are you bringing back hundreds of records from the database?" And, more importantly, "Should you be bringing back hundreds (or thousands) of records?" One commenter noted that: The [Speed Feak] article shows how performance degrades all the way up to 10,000 records... realistically you should never be displaying a client more than 100-200 over the web if not for performance purposes but just readability.I agree wholeheartedly, but what one "should do" vs. what one is "asked to do" can be two different things. I've had clients in the past who, despite my suggestions, were adamant about having large amounts of data shown on the page, be it a gargantuan DataGrid or a drop-down list with hundreds (or even thousands - eep!) of records. Additionally, many developers, when adding paging support to a DataGrid, either always use the default paging model or implement the default paging model at first with plans to later upgrade it to the custom paging model. Default paging, as you may know, is far less efficient than custom paging because it requires that the entire data to be paged through be brought back for each and every page, even though only a small subset of the data is actually shown. Custom paging is more intelligent - yet more difficult to implement - because it only retrieves the precise subset of data to display for the current page. (For more on default paging see An Extensive Examination of the DataGrid Web Control: Part 15; for information on custom paging, refer to my book, ASP.NET Data Web Controls Kick Start.) Even if you are able to convince your client to show only a reasonable amount of data per page, and even if you have the foresight and expertise to use custom paging on all of your pageable DataGrids, the performance gain from using DataReaders as opposed to DataSets would make your application snappier and more adept to scale.
What It All Boils Down To: Design/Develop-Time Efficiency vs. Run-Time Efficiency For read-only display data, Scott may have point. But for Web sites that collect information from the user and pass it back to the database, DataSets (or DataTables) are much more efficient because the data adapters have the update methods already constructed (auto generated code).If you are already familiar with the DataSet and/or working on a team that is familiar with that model, and if optimal run-time performance is not a concern, then you may find the DataSet to be a better tool for the job. Of course, not everyone enjoys the added features of the DataSet. Some, like this commenter, prefer the simplicity and higher degree of control that custom business objects affords: I totally agree with Scott on this one. The DataSet, although a very novel disconnected design, brings with it a rather complex model to support. The more they work into your architecture, the more cumbersome things can become. That statement comes from using them for things like reading XML into the DataSet and having to do a bunch of customized sorting. The syntax is right down bewildering...
Conclusion Happy Programming!
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
 |
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
| |||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||
