Ich habe eine Klasse Customer (mit typischen Kundeneigenschaften) und ich muss ein "Stück" von Customer Instanzen weitergeben und Datenbind. Zur Zeit verwende ich ein Array von Customer , aber ich habe auch Collection von T (und List von T verwendet, bevor ich von Collection von T wusste). Ich möchte den dünnsten Weg, um dieses Stück mit C # und .NET 3.5 zu übergeben.
Momentan funktioniert das Array von Customer gut für mich. Die Daten binden gut und scheinen so leicht wie möglich zu sein. Ich brauche nicht das Zeug List von T bietet und Collection von T scheint immer noch wie Overkill. Das Array erfordert, dass ich im Voraus weiß, wie viele Customer s ich zum Chunk hinzufüge, aber ich weiß das immer im Voraus (zum Beispiel Zeilen auf einer Seite).
Fehle ich etwas Fundamentales oder ist das Array von Customer OK? Gibt es einen Kompromiss, den ich vermisse?
Außerdem gehe ich davon aus, dass Collection von T die alte lose typisierte ArrayList veraltet macht. Bin ich gleich da?
Niemand hat den Rat der Rahmenrichtlinien erwähnt: Verwenden Sie nicht List<T> in öffentliche APIs :
Wir empfehlen die Verwendung von List in nicht öffentliche APIs aus zwei Gründen.
List<T>wurde nicht entwickelt, um erweitert zu werden. d. h. Sie können keine überschreiben Mitglieder. Dies bedeutet zum Beispiel, dass Ein Objekt, dasList<T>von a zurückgibt Die Eigenschaft kann nicht benachrichtigt werden wenn die Sammlung geändert wird. MitCollection<T>können Sie überschreiben SetItem geschütztes Mitglied zum Abrufen "Benachrichtigt", wenn neue Artikel hinzugefügt werden oder ein vorhandener Artikel wird geändert.Die Liste enthält viele Elemente, die in vielen Szenarien nicht relevant sind. Wir sagen Sie, dass
List<T>zu "beschäftigt" ist für öffentliche Objektmodelle. Vorstellen ListView.Items-Eigenschaft, die zurückgibtList<T>mit all seinem Reichtum. Jetzt, schau dir die tatsächlicheListView.Itemsan Rückgabetyp; es ist viel einfacher und ähnlich wieCollection<T>oderReadOnlyCollection<T>
Wenn Ihr Ziel auch eine zweiseitige Datenbindung ist, sehen Sie sich BindingList<T> (mit der Einschränkung, dass es nicht "out of the box" sortierbar ist!)
Ja, Collection<T> (oder List<T> häufiger) macht ArrayList ziemlich überflüssig. Insbesondere glaube ich, dass ArrayList in Silverlight 2 nicht unterstützt wird.
Arrays sind in einigen Fällen in Ordnung, sollten aber berücksichtigt werden etwas schädlich - sie haben verschiedene Nachteile. (Sie stehen im Mittelpunkt der Implementierung der meisten Sammlungen, natürlich ...) Ich würde mehr ins Detail gehen, aber Eric Lippert macht es so viel besser als je zuvor in dem Artikel durch den Link referenziert. Ich würde es hier zusammenfassen, aber das ist ziemlich schwer zu machen. Es lohnt sich wirklich, die ganze Post zu lesen.
Im Allgemeinen sollten Sie IEnumerable & lt; T & gt; oder ICollection & lt; T & gt; (Abhängig davon, ob es für Ihren Kunden sinnvoll ist, Artikel hinzuzufügen).
Wenn Sie eine unveränderliche Liste von Kunden haben, ist das ... Ihre Kundenliste wird sich nicht ändern, sie ist relativ klein und Sie werden sie immer zuerst durchlaufen und Sie müssen sie nicht zur Liste hinzufügen oder entfernen Sie es, dann ist ein Array wahrscheinlich in Ordnung.
Wenn Sie jedoch unsicher sind, dann ist Ihre beste Wette eine Sammlung von irgendeinem Typ. Welche Sammlung Sie auswählen, hängt von den Vorgängen ab, die Sie ausführen möchten. In den Sammlungen geht es um Einfügungen, Manipulationen, Suchen und Löschen. Wenn Sie häufig nach einem bestimmten Element suchen, kann ein Wörterbuch am besten sein. Wenn Sie die Daten sortieren müssen, funktioniert vielleicht eine SortedList besser.
Ich würde mir keine Sorgen um "leichtgewichtig" machen, es sei denn, Sie sprechen eine riesige Anzahl von Elementen, und selbst dann überwiegen die Vorteile von O (1) -Lookups die Kosten von Ressourcen.
Wenn Sie eine Sammlung "weitergeben", übergeben Sie nur eine Referenz, die im Grunde genommen ein Zeiger ist. Es gibt also keinen Leistungsunterschied zwischen dem Übergeben einer Sammlung und eines Arrays.
Ich stimme Alun zu, mit einem Zusatz. Wenn Sie den Rückgabewert durch den Index myArray [n] adressieren möchten, verwenden Sie eine IList.
Ein Array unterstützt IList (wie auch IEnumerable und ICollection). Wenn Sie also an der Schnittstelle vorbeikommen, können Sie das Array immer noch als zugrunde liegende Datenstruktur verwenden. Auf diese Weise müssen die Methoden, an die Sie das Array übergeben, nicht wissen, dass die zugrunde liegende Datenstruktur ein Array ist:
%Vor%Ich werde sowohl Jon als auch Eric Lippert ein abweichendes Argument unterbreiten, was bedeutet, dass Sie meiner Antwort in der Tat sehr müde sein sollten!).
Das Herz von Eric Lipperts Argumenten gegen Arrays besteht darin, dass die Inhalte unveränderlich sind, während die Datenstruktur selbst dies nicht ist. In Bezug auf die Rückgabe von Methoden ist der Inhalt einer Liste genauso veränderlich. In der Tat, weil Sie Elemente aus einer Liste hinzufügen oder subtrahieren können, würde ich argumentieren, dass dies den Rückgabewert mehr veränderbar macht als ein Array.
Der andere Grund, warum ich Arrays mag, ist, dass ich irgendwann einen kleinen Abschnitt mit performancekritischem Code hatte, also habe ich die Leistungsmerkmale der beiden Benchmarks verglichen und Arrays aus dem Wasser gejagt. Nun, lassen Sie mich dies mit dem Hinweis absprechen, dass es ein enger Test dafür war, wie ich sie in einer bestimmten Situation anwenden würde, und es widerspricht dem, was ich von beiden verstehe, aber die Zahlen waren wild verschieden.
Wie auch immer, hört Jon und Eric =), und ich stimme zu, dass List fast immer mehr Sinn macht.
Tags und Links arrays c# generics collections