ISet. However, I've encountered a situation in my main project where an association's many-side is indexed, i.e. the corresponding collection is an
IList. So I'm revisiting the ObservableCollections project in order to accommodate this need.
Looking back at the bidirectional association helper classes after so much time, I realised how confusing the class and method names have been. So the first step was to rename them. For starters, I renamed the
OneToManyAssocSyncto reflect the more general (albeit incomplete Although I will add support to the newly named
OneToManyAssocSyncclass for indexed collections, this more general name isn't completely applicable since I won't be adding support for non-unique collections as well.) desired applicability. And I renamed the
ManyToManyAssocSync. After that, in the
OneToManyAssocSyncclass, I changed other occurrences of "setContainer" to say "one" or "oneSide" since it has a multiplicity of one in the relationship. And I changed "entity" to say "many" or "manySide" since it has a multiplicity of n in the relationship. Finally, I renamed some miscellaneous variable names so that they, to, will be consistent with this new terminology.
The next step was to modify the
UpdateOneSidemethod, along with the
UpdateOtherSidemethod, as follows. The other side's collection must be cast not to
ISet, but to the ancestor type
ICollectionwhich is common to both
IList. I actually ended up using the generic
ICollection<T>since the nongeneric version strangely lacks methods for adding, removing, and checking for containment of items. The code now works in cases the collection type is an
IList; however, it only works when the uniqueness constraint is being applied to the
IList, which is fine in the case of my main project. It will not, however, work for bags or lists with multiple occurrences of the same item. I included checks for this boundary condition.