The OrderedDictionary overloads the indexing operation so that indexing with an integer N will get the item in position N, while indexing with an Object will retrieve the item coresponding to that object. If one were to create an OrderedDictionary<int, string> called myDict, and added items (1,"George") and (0,"Fred") in that order, should myDict[0] return "George" or "Fred"?
Such an issue could have been resolved by imposing a class constraint on the key type. On the other hand, much of the usefulness of generic collections stems from their ability to efficiently work with value types. Imposing a class constraint on the key type would seem a little ugly.
If the class didn't have to be CLS compliant but merely had to work with vb.net, a sensible design might have been to used named indexed properties. Thus, in the example above, myDict.ByKey[0] would have yielded "Fred", and myDict.BySequence[0] would have yielded "George". Unfortunately, languages like C# do not support named indexed properties. While one could have kludged something to allow use of the above syntax even without such properties, the unfortunate decision to wrap the fields of structures like Point and Rectangle means that for myDict.ByKey[0] = "Wally" to work, myDict.ByKey would have to return a new class object. A struct would be more efficient, but compilers would reject what looked like a write to a read-only structure (notwithstanding that the property wouldn't modify the struct returned by ByKey, but instead modify the collection to which it holds a reference).
Personally, I think a dictionary-ish object that was specified as keeping track of the insertion order would be a nice thing to have; I'd also like to have a dictionary-ish object which could easily return the key associated with a particular key (so that, e.g. if one has a case-insensitive dictionary and has added a record with a key of "GEORGE", one could ask the dictionary what key is associated with "George" without having to search through all the KeyValuePair objects returned in an enumeration.
So I'm not sure "terrible" is the best word here. However, it has limitations, and as soon as your needs do not fit how the membership provider was designed you end up with a lot of glue code. If you can use the membership provider out of the box, I would say go for it. As soon as you start writing a custom one I question using the membership stuff anyways.
In my experience the membership provider buys you...
- Sign up already built in for MVC app
- Account editing
- Forgot Password is easy to hook up
- Validate user method
I'm sure there's something else I'm missing but I think those are the big ones. Now when you need custom password management, two factor authentication, to work with an existing data model, or a whole host of other things you start to lose out. The code that's already written for you with the membership provide should take on the order of a few days to duplicate if you know what you're doing.
Best Answer
I can conceive of only one benefit of having a circular reference, and even that is rather dubious: less libraries/modules. In order to resolve such a reference between two entities A and B, one usually needs to introduce a third entity C that contains whatever A and B need in common:
I think that circular dependency was introduced by mistake, and now it is too late to disentangle the libraries involved because, for example, it will break backwards compatibility through the relocation of some public classes or methods.