I guess part of what I was wondering was if it would be worth the effort to implement IBindingList for a collection instead of using the implementation provided with a dataset. I always thought that a dataset seemed overkill for just binding a bunch of objects to a listbox, but then I found it useless if I wanted to add/remove items from the listbox.
I'd be interested if anyone has any examples of a collection that implements IBindingList. The collection does seem to be the cleaner, more OO way to go (especially once we get generics in 2.0), but currently it's lacking. What'd be really nice is if another class, say CollectionBindingBase, could be derived from CollectionBase so that if you want a collection for databinding, it's simply a matter of deriving from the correct base... --Oren > -----Original Message----- > From: Moderated discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED]] On Behalf Of Ian Griffiths > Sent: Monday, October 07, 2002 7:15 AM > To: [EMAIL PROTECTED] > Subject: Re: Strongly-Typed DataSets vs. Strongly-Typed Collections > > 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. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
