>I hope you won't mind if we continue to agree to disagree on this issue. <s>
Nah not all <g>...
>OK, well, you're the web expert and I'm a WinForm expert, so you may be right about the time issue. Still, I can't see where anyone is going to notice a 6/100th of a second's time difference in getting their data.
It is for Web applications because it occurs on every page hit against the server. Well, I guess if you have an app that's not high load or that does lots of long requests indeed it isn't going to matter that much, but if you have a transactional site where requests run in less than a 100th of a second generally this soon becomes a big bottleneck.
>
>Right but that of course diminishes the whole point of a typed DataSet doesn't it?<>
>True, it does. If you're going to be doing dynamic queries on a regular basis, then perhaps typed DataSets aren't appropriate. There are certainly times where I don't use them, but the majority of my DataSets are Typed.
Yeah definitely true there's nothing stopping anyone from using untyped dataset access alongside the typed access, but that becomes very inconsistent in applications. Sometimes you do, sometimes you don't.
>
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.<>
>Yeah, well, it's not automatic, so what ... there's nothing wrong with using tools. I use home-grown ones, but the point is that with your approach (using objects), you still have customized generation tools that you need to use. There's really no difference.
Well, the difference is if I'm going through the trouble of generating that code anyway, then what's the benefit of the typed DataSet? All you get is the bloat without any addition benefits.
>Ah hah! Here's where we agree on something (I knew there *had* to be something <g>). Well, more or less maybe ... I have always said that you don't want to return a DataSet from a Web Service, you should only return your DataSet serialized to XML (IOW, MyDataSet.GetXml()). I know what you're gonna say ... that's a lot of overhead, cuz the XML is pretty heavy. That may be so, but we've got pretty large DataSets (100+ tables in some of them) and returning this kind of XML over the wire has not been a problem so far and we don't anticipate that it will ever be a problem.
Nope - still no agreement there.
Not all XML is equally created XML <s>. Consuming DataSet XML is not an official data formatted that is supported by a Web Service. If you look into a WSDL file for example, take a close look at the schema generated for a DataSet - ah, there's no schema: The DataSet is sent as a raw XML entity. And that's where the problem lies.
Outside of .NET that dataset is not very usable - yes you can parse the XML manually, but that's a bit suboptimal. IOW, it's not a universal format - roughly it's .NET to .NET only. For the most part I suppose: VFP for example can consume it indirectly (treating it as XML then using XmlAdapter for example, which is slow and non-transparent). Things like Flash Remoting also can use it directly, but beyond that there's not a lot of places where DataSets are actually supported.
I'm not bagging on DataSets in general. Even given my misgivings of many aspects of DataSets I use them because they are the easiest way to build consistent data structures in .NET in a reusable fashion even if they are often not the best performing solution (DataReaders usually are much faster). But I just don't see the benefit of typed data sets if you have to auto-generate the structural data anyway. You might as well go the extra step and create real objects that play much nicer in connected environments and work without the load overhead.
