Sammlung Lookups; Alternative zum Wörterbuch

Question

Eine TimeSheetActivity Klasse hat eine Sammlung von Verrechnungen. Eine Zuordnung ist ein Wertobjekt, das auch von anderen Objekten in der Domäne verwendet wird, etwas wie folgt aussehen:

public class Allocation : ValueObject
{
    public virtual StaffMember StaffMember { get; private set; }
    public virtual TimeSheetActivity Activity { get; private set; }
    public virtual DateTime EventDate { get ... }
    public virtual TimeQuantity TimeSpent { get ... }
}

Doppelte Zuweisungen für das gleiche Allocation.EventDate sind nicht erlaubt. Also, wenn ein Client versucht, eine Zuordnung zu einer Aktivität zu machen, wird geprüft, um zu sehen, ob es in der Kollektion für die gleiche Allocation.EventDate bereits eine Zuweisung ist. Wenn nicht, dann wird die neue Zuordnung zu der Sammlung hinzugefügt, aber wenn dem so ist, wird die bestehende Zuweisung durch die neue ersetzt.

Ich bin derzeit ein Wörterbuch, die Sammlung zu erhalten, mit dem Allocation.EventDate als Schlüssel. Es funktioniert für die Domain in Ordnung, aber ich frage mich, ob die Tatsache, dass der Schlüssel bereits Teil des Wertes ist nicht selbst ein ‚schlechter Geruch‘.

Ich habe auch keinen Grund, etwas anderes als die Wörterbuchwert zu beharren. Weil ich NHibernate bin mit, kann ich brauche einige benutzerdefinierte Art schreiben tun, und ich frage mich, ob das auch ein Hinweis ist, dass ich sollte eine andere Art der Sammlung werden. (Das ist auch der Grund für die virtuellen Objekte in der Allocation-Klasse).

Die primäre Alternative ich denke wäre ein HashSet mit einem dedizierten EqualityComparer.

Was denken Sie?

Cheers, Berryl

Answer 1

Wenn Sie einen externen Vergleich verwenden, um eine HashSet<Allocation> zu tun, würden Sie sehr vorsichtig sein, nicht das Datum zu ändern, ohne den Wert im Wörterbuch Re-Keying. Sie haben dieses Problem so oder so, aber es wird von Veränderlichkeit (zumindest mit Dictionary<,> es wird immer noch in der Lage ihre eigenen Schlüssel und Werte zu verfolgen) verschärft. Mit einem wandelbaren Wert als Teil des Schlüssels riskieren Sie nie wieder den Wert sehen ...

Wenn ich habe im Zeitplan Systeme in der Vergangenheit habe ich eigentlich SortedList<,> dafür verwendet haben -. Ähnlich, aber nützlich, wenn Sie in der Regel die Daten in der Reihenfolge möchten, und ermöglicht es binäre Suche, wenn die Daten ziemlich einheitlich

Answer 2

Ich glaube nicht, dass der Schlüsselteil des Wertes ist notwendigerweise ein Problem. Nach meiner Erfahrung das ist ziemlich häufig der Fall für Wörterbücher. Ein HashSet mit einem entsprechenden Gleichheitsvergleich würde sicherlich arbeiten, so lange, wie Sie nie mit einem bestimmten EventDate auf das aktuelle Objekt erhalten benötigt. Das scheint wie eine nützliche Sache der Lage sein, zu tun, möglicherweise ...

Sind Sie zur Zeit nur besorgt in etwas vage, oder haben Sie einen konkreten Verdacht, wie dies könnte Sie beißen?

Answer 3

die Standardbibliotheken verwendet, gibt es keine bessere Lösung, die ich kenne. Allerdings fühlte ich mich auch diese Art von Code, um einen „schlechten Geruch“ zu sein, aber es ist wegen der Sammlung Klassen in der BCL und nicht den Code.

Ich weiß nicht, warum MS nicht generisch Sets<TKey, TData> where TData: IKeyed<TKey> erstellt hat oder so statt Wörterbücher, da diese solche Datenstrukturen Implementierung erlauben würde, wo der Schlüssel Teil der Daten ist. Die KeyValuePair<TKey, TValue>: IKeyed<TKey> wäre nur ein Helfer Struktur der diese Schnittstelle implementieren und so dass identische Wörterbuch-Funktionalität zu schaffen, wie wir sie jetzt haben.

Auch (mit der kleinen Tirade fortzusetzen) Ich frage mich, warum sie nicht den Begriff der deklarativen unveränderlicher Typen hinzugefügt haben und dies eine mögliche generische Typ Einschränkung machen, denn dies ist ein Schlüssel machen würde erlauben, dass während der Laufzeit nicht seinen Hash-Code ändern (was zur Zeit passiert, wenn man GetHashCode() und Equals() auf einige veränderbares Objekt implementiert).