Hallo Tachyon,

ich würde einfach einen zusammengesetzten Schlüssel implementieren.
Die Frage ist für mich, was Du mit einem zusammengesetzten Schlüssel meinst? Wenn Du damit soetwas in Deinem 2. Vorschlag meinst (also ein Tuple<Key1,Key2>), dann würde ich das zumindest schon mal als eigene Klasse MyCompositeKeyXY implementieren. Dann kann ich in dieser Klasse GetHashCode(), Equals, ==, !=, .. also alles was ein nichtsortierbarer Schlüssel mitbringen muss implementieren. Damit kann ich dann schlussendlich wieder ein "herkömmliches" "Dictionary<TKey = MyCompositeKeyXY, TValue>" verwenden.

Wenn Du aber wie in Deinem 1. Vorschlag einen zweistufigen Schlüssel meinst, würde ich eine eigene Collection implementieren, also keinen eigenen Schlüssel (solange die im Standardverhalten vergleichbar sind).

Auch wenn man mit Deinen beiden Vorschlägen mehr oder minder dasselbe erreichen kann, sind über den Code die Absichten nicht klar kommuniziert. Deshalb würde ich an Deiner Stelle versuchen, Deine Intention expliziter (in Form eines oder mehrerer Typen) zu formulieren.

UPDATE: Ich greife Matthias Kommentar auf und nutze meinen Post für eine Antwort (der Länge wegen)

Gegeben ist folgender Code:

class SomeClass
{
    public string Text { get; set; }
}

static void Main(string[] args)
{
    SomeClass newSomeClass = new SomeClass() { Text = "abc" };
    Tuple<int, SomeClass> tuple1 = new Tuple<int, SomeClass>(5, newSomeClass);
    Tuple<int, SomeClass> tuple2 = new Tuple<int, SomeClass>(5, new SomeClass() { Text = "abc" });
    Tuple<int, SomeClass> tuple3 = new Tuple<int, SomeClass>(5, newSomeClass);

    Console.WriteLine(tuple1 == tuple2);    // false
    Console.WriteLine(tuple1 == tuple3);    // false

    Console.WriteLine(tuple1.Equals(tuple2));   // false
    Console.WriteLine(tuple1.Equals(tuple3));   // true

    Console.ReadKey();
}

Das Ergebnis des Vergleichs differiert je nach verwendetem Vergleich (==, Equals). Ein Tuple (IStructuralEquatable) führt keinen Referenzvergleich durch, sondern einen elementweisen Wertvergleich. Das Verhalten, welches obiges Codebeispiel zeigt, halte ich für hochgradig gefährlich. Die Berechtigung für einen eigenen Typ leite ich direkt aus diesem Verhalten ab. Selbst wenn ich SomeClass IEquatable implementieren lasse, ändert es nichts. Ein Entwickler muss sich also durch all dieses Zeugs denken, nur weil ein anderer Entwickler seine Absicht bzgl. dieses Schlüssels nicht klar in Form eines eigenen Typs formulieren wollte. Was ich allein deshalb schon fordere, weil ich ihm einen eigenen Namen verpassen kann.

Als zusammengesetzten Schlüssel bezeichne ich für mich einen Schlüssel, der aus mehreren einzelnen Typen besteht und als Einheit vergleichbar ist. Einen solchen zusammengesetzten Schlüssel kann ich (wenn er anständig implementiert ist) ganz normal in einem herkömmlichen Dictionary einsetzen. Der Lookup mit dem zusammengesetzten Schlüssel führt mich zu einem Value.

Einen zweistufigen Schlüssel sehe ich dann, wenn der Schlüssel eben nicht zusammengesetzt ist (also keinen eigenen Typ darstellt), und ich einen zweistufigen Lookup durchführe, also mit dem ersten Schlüssel eine Menge abrufe, in der ich dann mit dem zweiten Schlüssel arbeiten kann. Je nach beabsichtigtem Ergebnis macht das einen Unterscheid zu einem zusammengesetzten Schlüssel.

Was am Ende erreicht werden soll, bleibt IMHO bei untypisierter Benutzung subjektiv. Klar können beide Varianten verwendet werden, aber das ist ein Implementierungsdetail. Wichtiger ist, dass über saubere Typisierung und suggestive Namen Code entsteht, der wartbar ist und tunlichst keine Zweifel zulässt.

Viel Erfolg
Florian