Has anyone tried to create a BusinessListBase descendant from KeyedCollection? I was looking at using a dictionary in order to find items by key values since I have large lists. I found the abstract KeyedCollection which seems to be a good solution since it can be accessed by both a key or an index. Also since it implements IList(of T) the sorting and filter binding lists should work so you can easily get a view to bind to a grid which is not possibly to do with a dictionary.
Thanks,
HappyJack
I think the issue you'll face here is that dictionary/hashtable and other keyed lists won't data bind - at least not directly. Nor will SortedBindingList auto-fix this, because the items in the list are some complex type, not your actual data (each item is the key/value pair).
So if you want data binding, you can't have a keyed list and visa versa.
However, if you are willing to forego data binding, there's no reason why you couldn't create your own base class similar to BLB by inheriting from one of the existing keyed list types and adding code similar to what's in BLB.
Rocky,
Thanks for the response. I agree that this was the issue with the old HashTable or even the Dictionary. But the abstract System.Collections.ObjectModel.KeyedCollection(Of TKey, TItem) is an IList(of T) instead of the ICollection(of KeyValuePair(Of TKey, TValue)). So this means that the items are not a complex type like you suggest. Also since this is an IList(Of T) then you can databind with it directly or you could use the sorting and filter bindinglist helpers to get a different view. So I guess the real difference is that this is an IList(of T) instead of the BindingList(Of T) so it would not be as a friendly with databinding. I'm not sure how difficult it would be to implement all the interfaces that BindingList(of T) implements. Thanks for any other information about this.
Thanks,
HappyJack
Ahh, I see.
Well then you'd have your work cut out for you a bit. To emulate BindingList<T> you need to implement:
The latter two are pretty straightforward as far as I know, but IBindingList is complex and idiosyncratic. On the other hand, you can look at BusinessCollectionBase from CSLA .NET 1.53 to see an implementation of that interface, and you could probably build on that as a start - though some work would be required to accomodate the CSLA .NET 2.1.4 model.
Another way, which I've used a couple of times is to have a hashtable, that holds the key and index of the object, contained within your BusinessList.
In your DataPortal_Fetch, you first add the fetched object to your BusinessListBase and then add an entry into your hashtable with the objects key and it's index in the list.
Then add a FromKey method to your BusinessList that looks the objects index up in the hashtable by key ~O(1) and return the object from the list on that index.
I only use this method if I need really fast lookups. Most times a simple for each loop O(n) will perform well enough.
Cheers
/Henrik
I agree, after thinking about it some more I think it would be easier to do excatly that which is the same thing that Rocky suggested years back. I just found the KeyedCollection in the .Net framework the other day and I always like trying to figure out where and when it makes sense to use the built-in framework classes. In this case, I think I would lose to much binding functionality and it would be too much work to put that back in when the result at the end of the will be the same.
Thanks,
HappyJack
Copyright (c) Marimer LLC