Is there a structure identical to IEnumerable<KeyValuePair<TKey, TValue>>?

Question

I'm using a structure which can be represented as:

IEnumerable<KeyValuePair<TKey, TValue>>

Given that it's too long to write (not counting that Code analysis will probably emit a warning), I would prefer using some more expressive type. Is there such type in .NET Framework, or should I create my own?

Note that it's not the same as a dictionary:

IDictionary<TKey, TValue> : IEnumerable<KeyValuePair<TKey, TValue>>

since a dictionary ensures that every key is unique, which is not my case. I can't use a lookup neither:

Lookup<TKey, TValue> : IEnumerable<IGrouping<TKey, TValue>>

because the lookup is not lazy, ie it will require all data to be flushed in order to group it.

Answer 1

If you have two specific types for the key and the value you can use type aliasing by doing:

using PairSequence = System.Collections.Generic.IEnumerable<
    System.Collections.Generic.KeyValuePair<string, int>>;

Answer 2

That is as good as it's going to get. The struct KeyValuePair doesnt implement much in the way of interfaces. You could of course create your own interface using interface inheritance basically letting you rename IEnumerable<KeyValuePair<TKey, TValue>> , but you lose more than you gain by doing this, because types that implement IEnumerable<KeyValuePair<TKey, TValue>> would not implement your custom interface.

Answer 3

(half joking, half serious)

IEnumerable<KeyValuePair<TKey, TValue>>  <= length: 40 chars
IEnumerable<Tuple<TKey,TValue>> <= length: 32 chars
IList<Tuple<TKey,TValue>> <= length: 26 chars

You might be able to mangle some using usage in some cases, as well:

using IEI = IEnumerable<int>;   // for example

Answer 4

除了您已排除的Dictionary之外，我不知道框架中有什么代表这样的结构。

Answer 5

不在.NET Framework中，否。

Answer 6

The problem with just implementing IEnumerable<KeyValuePair<TKey,TValue>> is that you don't have any backing store.

As a general rule, you should implement types that represent things in your problem domain, even for things like numbers and strings. Using a string to represent a zip/postal code, for instance, doesn't tell you much about the datatype, but having a custom data type called PostalCode tells you a lot more. Even better would be an abstract data type PostalCode (which might have country-specific concrete implementations).

Your custom types, especially with collections, can expose just the functionality you need without providing all the functionality that the non-specific collection classes do. Further, you can implement domain restrictions pertinent to your problem domain. For instance, a concrete UsZipCode that inherits from the abstract type PostalCode might restrict the value to being either 5 or 9 decimal digits, whilst a concrete CanadianPostalCode might require the value to consist of 2 3-character alphanumeric sequences.

But I digress.

I'd probably simply create my own class like this:

public class MyListOfKeysAndValues : IList<KeyValuePair<MyKeyType,MyValueType>>
{
  private List<KeyValuePair<MyKeyType,MyValueType>> MyBackingStore ;
  ...
}

Exposing the minimal methods/properties needed.