<g>

>LOL!! I'm sure that we've disagreed on this one before, Rick. But that's ok.
>
>Slow to load? I don't think so. I just did some benchmarks on a 27 table typed DataSet. We have larger ones in our app, but this just happens to be the one I was currently on.

>Instantiating that DataSet (the first time it's used) took .06 seconds. Wow! That'll really bring my app to it's knees. After it's been instantiated once, it takes 0 seconds to instantiate subsequently ... yeah, I suppose that's because it's caching it all in memory, but so what ... I don't necessarily see that as a bad thing, maybe you do.

Uh huh. .06 seconds is longer than most of my requests run TOTAL in a Web application. And that's exactly the point. The first hit against a DataSet is very slow because it has to load up all those column objects etc.

This might not be a big deal in a WinForm application but it's a huge issue in Web applications.

>Won't work if you return anything other than what they're designed for?

> Well, that all depends on what you mean by "won't work" ... the DataSets will work just fine. It's just that you won't have the strong typing for any additional columns or tables that you may have returned and you'll have to use the regular DataSet syntax for accessing those extra columns or extra tables. No big deal.

Right but that of course diminishes the whole point of a typed DataSet doesn't it?

The other reason that I don't like typed DataSets is that there's no easy way to tie it to a database schema so you can keep things in sync. Change the database and your typed DataSet is hosed. You always have that syncing issue.

You can get around that with auto-generation with things like CodeSmith, but this sort of thing should be automatic.

FWIW, I use a semi-entity approach that provides 90% of the benefits of typed data sets without the overhead of having to generate these huge dataset structures but getting the strongly typed aspect as well as the ability to use partial results with the strongly typed interface.

IMHO, that gives you the benefits that the DS provides (synchronizability, automatic serialization deserialization) plus the strong typing which is undoubtably the main reason to use typed datasets.

The other big issue that sucks with DataSets in general is that the Serialization format is a) bloated and b) not supported outside of .NET for the most part. Plain object serialization is more efficient and more easily understood by non-.NET Web Service clients for example. Since a lot of my applications are service based DataSets as results are a no-no.

The semi-entity mechanism also addresses this by providing real objects that are not actually hard tied to the dataset while optionally referencing it. This makes it possible to use DataSets for data representation while exposing POCO objects externally.

But no doubt: it's a custom approach, and also requires generation tools (also custom) to make happen, but if you're already going down that path of code generation anyway one might as well go to a data representation that actually works more widely, since you can use the Dataset's internal structure to manage the data updating/loading aspects, which while not optimal (compared to say a DataReader) do offer the most bang for the buck.



+++ Rick ---