Hey Kevin,

>1) Out of curiosity, were your tests with VS '03 or VS '05? What kind of times were you experiencing?
>
>I took two datasets from a client application. One is a single table with a flat structure of invoice data, the second a normalized result set for an aging report (5 tables with some relations, calculated columns).
>
>In a Winform environment, they took 10 and 30 milliseconds respectively to instantiate the first time. Then I ran a test on my client's test web environment, and they took 80 and 160 milliseconds respectively. (Subsequent instantiations were all less than 1 millisecond). Is that consistent with what you've found?

It's been some time and I didn't run any true comparison tests. But the difference was very noticeable in the applications.

Now, it should be said that the typed dataset was one big dataset definition for the whole app (not very big but there are about 20 tables).

I don't think there's a performance problem with the actual dataset access mechanism - that'll be in sync with non-typed datasets, but it's the load time and initialization that's the problem especially in Web apps because the thing has to be reloaded on every page.


>2) Right now I have two clients with other vendors that are using our XML services (ironically, one is VFP and the other is Java). They're not what I would call high-end services, but were fine with the output we generate. That's the first time I've heard it characterized as a burden. Can you point out any online references or sources that talk about this? (not a challenge, I'm genuinely curious to learn more about this)

I don't think you have to search very hard to find content on this subject <s>...

Here's one of my favorites from Scott Hanselman:

http://www.hanselman.com/blog/ReturningDataSetsFromWebServicesIsTheSpawnOfSatanAndRepresentsAllThatIsTrulyEvilInTheWorld.aspx

The primary issue is that DataSets returned from a Web Service are not schema'd in the WSDL which means the non-.NET client will have to manually parse the data. If you return typed collections (or otherwise use contract first Web Services) the data will be self-discoverable and consumable as such.

On top of that you often have to 'reattach' the dataset/datatable context with a database in order for you to actually be able to do something with the data on the client (like save it). There can be a fair amount of effort involved in this process.


>3) I'll grant (IMO) that typed DataSets yield more benefits in certain applications, but I really have yet to experience first-hand any situation where they were a detriment (thus my questions to you, to try to understand more specifics on how/when they're a downfall).
>
>If every layer is .NET, then you have the option of serializing in a binary format (in VS '05), and they can make apps with large reporting requirements a little easier to develop. I don't have an issue with writing custom collections, I just like the extra functionality that comes with typed datasets (an opinion shared by some ASP.NET authors, articles from 4GuysFromRolla, Scott Guthrie, MSDN articles, etc.) Sure, there seem to be about as many who intensely dislike them - sometimes I think this is almost as polarizing an issue as the C# vs. VB.NET language wars.

Yup. DataSets have many nice features but they are very heavy and very memory intensive because they have lots and lots of support objects to map besides the actual data.

And keep in mind I'm not really anti-Dataset either primarily because I think most alternatives don't provide the full set of functionality that DataSets provide. However, I also feel that datasets are overly complicated in their design (internally) and unnatural to use. There are lots of little things you have to know about them internally (ie. completely non-obvious) to do even some simple things. For example, adding rows to a datatable is not seomthing that I would call 'intuitive' <s>...