For me the principal reason not to use a DataSet when I don't actually need one is the unnecessary complexity of the class. This is mostly an issue with Intellisense... I don't like being confronted with 40 items in my intellisense list that I mostly don't care about. A strongly-typed collection will have fewer than half that number. (Which is still more than I'm interested in most of the time, but at least it's less than 2 pages on the Intellisense.)
Some might argue that this is a fairly trivial reason, which is fair enough I suppose. But I find Intellisense very important, and I find its utility is somewhat diminished when there are pages and pages of members. Also, isn't the syntax a little more long-winded with a typesafe dataset, e.g. myDs.MyTable[42] instead of myColl[42] The latter certainly looks simpler to me! Also, I get nervous about the overhead of a dataset. It carries a whole bunch of metadata cruft with it, and it tracks changes (i.e. if I modify a bunch of rows, it actually remembers which rows I modified). OK, so you can call AcceptChanges from time to time, but again that's extra complexity I just don't see the point of dealing with. I have to admit to not having actually profiled the difference - I choose collections on the basis of slightly simpler programming, and have never had cause to find out whether they are actually noticably faster (or even slower) than datasets. Also, the fact that the DataSet is *able* to implement IBindingList and thus support updating is a fairly obvious clue that it is likely to be working rather harder than a simple collection class. Also, when collections are already available, they're just easier to use, IMO. Do you think it's simpler to write this: StringDictionary sd = new StringDictionary(); or to build an XSD that represents a string dictionary and build a typesafe dataset for it? Also, your argument is essentially one of "Why use tool (a) to generate a typesafe container when I could just use tool (b)?" The answer is presumably to use whichever tool builds something closest to your needs. If you have a use for the extra functionality offered by a dataset (e.g. you need to do databinding) then use a dataset. If you don't, why bother with the extra complexity? -- Ian 'Devil's Advocate' Griffiths DevelopMentor ----- Original Message ----- From: "Oren Novotny" [EMAIL PROTECTED] > I was curious as to why one would want to use a strongly-typed > collection (generated from a tool of some such) versus using a > strongly-typed dataset (generated from an xsd). > > Here's why I'm asking: I figured a collection would be easier since I > had a bunch of objects and I wanted to be able to add/remove them, etc. > But then I also wanted to databind them to a listbox control. Here's > the catch: while the databinding works (since the collection implements > IList), it's not really useful. If you add/remove/change elements in > the databound collection, the listbox is not updated. It's not very > well documented, but if you want auto-updating to work, then your > collection must implemente IBindingList[1]. Among classes that do > implement that interface are DataView's, DataTable's, and DataSet's. > > So that begs the question. Why not just always use a strongly-typed > DataSet, since that way databinding will always work as expected. > > Is there some reason not to use one over the other? What about > performance? At what point is one worth the trade-off of the other? > > It seems like you can create a simple XSD using the designer that has > the same functionality as a custom collection. Just put a single > Element there and in it, put your columns and types. If you want, set a > primary key. That very nicely corresponds to a collection of a given > type... > > Any thoughts? You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
