Wie viel sollte ein DataSet darstellen?

Question

Wie viel sollte ein DataSet darstellen?Am Beispiel eines Bestellsystems:Während ich Ihre Bestellung zeige, zeige ich auch eine Liste von Artikeln, die einem Ihrer Artikel ähneln, sowie eine Liste unserer beliebtesten Artikel.Während Ihre Artikel in einem Netz von Beziehungen zwischen Ihnen und Ihren früheren Bestellungen, bevorzugten Lieferanten und den verschiedenen anderen Arten von Informationen über Sie als Kunde verwickelt sind, bestehen bei den anderen Artikeln nicht dieselben Beziehungen.Die Abfragen, die ich verwende, um durch die Sie repräsentierenden Elemente zu navigieren, unterscheiden sich von den Abfragen, die ich für eine dieser anderen Elementlisten verwende.

Ich neige dazu, verschiedene DataSets für verschiedene Arten von Beziehungen zu erstellen, aber dann erstelle ich zehn separate Element-DataTables, und das scheint falsch zu sein.Wenn ich das größere DataSet instanziiere, obwohl ich nur an einer kleinen Teilmenge interessiert bin, scheint das falsch zu sein, und wenn ich versuche, all dies in ein DataSet zu packen, habe ich ein großes, unordentlich aussehendes Ding mit mehreren Elementtabellen nebeneinander, und das tue ich auch Ich bin mir ziemlich sicher, dass das falsch ist.

Vielleicht überbewerte ich die Beziehungsfunktion von DataSets, oder vielleicht muss ich einfach über mich selbst hinwegkommen, so oder so könnte ich eine Anleitung gebrauchen.

Answer 1

Aus diesem Grund verwende ich keine Datensätze.Wenn Sie stark typisierte Datensätze verwenden, profitieren Sie von der starken Typisierung, zahlen dafür aber in Bezug auf die Zeit, die zum Erstellen eines Datensatzes benötigt wird, selbst wenn Sie nur einen Teil davon verwenden, und in Bezug auf die Erweiterbarkeit in Bezug auf die Codebasis.Wenn Sie eine vorhandene ändern möchten und eine Zeilendefinition ändern, führt dies zu „Schrotflinten“-Brüchen in der Codebasis, da jede Definition zum Hinzufügen einer neuen Zeile geändert werden muss, da sie nicht mehr kompiliert werden kann.

Um das oben beschriebene Szenario zu vermeiden, besteht der sinnvollste Ansatz darin, generell auf eine sinnvolle Wiederverwendung zu verzichten.Definieren Sie einen Datensatz pro Zweck und pro Verwendung.Das Hauptproblem hierbei ist jedoch die API-Nutzung. Am Ende erhalten Sie einen Datensatz, der einem anderen Datensatz ähnelt. Da es sich jedoch um einen anderen Datensatztyp handelt, müssen Sie ihn umwandeln, um die gemeinsame API zu verwenden, was sowohl umständlich als auch unelegant ist.

Dies und die Tatsache, dass stark typisierte Datensätze Ihren Code schrecklich aussehen lassen (die Länge der Typdeklarationen), sind so ziemlich die Gründe, warum ich Datensätze aufgegeben und stattdessen auf Geschäftsobjekte umgestiegen bin.

Answer 2

Das DataSet wird stark überbewertet und überstrapaziert.Verwenden Sie stark typisierte Sammlungen (Danke, Generika und automatische Eigenschaften!).Als Sahnehäubchen können Sie mit LINQ jetzt sogar coole Abfragen für Ihre benutzerdefinierten Objekte durchführen.

Guter Esposito-Artikel über Datensätze im Vergleich zu benutzerdefinierten Objekten:

http://msdn.microsoft.com/en-us/magazine/cc163751.aspx

Automatische Eigenschaften:

http://weblogs.asp.net/dwahlin/archive/2007/12/04/c-3-0-features-automatic-properties.aspx

LINQ mit Ihren Objekten:

http://blogs.msdn.com/wriju/archive/2006/09/16/linq-custom-object-query.aspx