C#:Was Verwenden Sie Neben DataSet

https://stackoverflow.com/questions/18533

09-06-2019
|

Frage

Ich habe mich zunehmend unzufrieden mit dem DataSet/DataTable/DataRow-Paradigma .Net, vor allem, weil es oft ein paar Schritte komplizierter als das, was ich wirklich tun will.In den Fällen, wo ich mich verbindlich zu den Kontrollen, Datensätze sind in Ordnung.Aber in anderen Fällen scheint es zu sein, eine faire Menge der mentale overhead.

Ich habe schon ein bisschen mit SqlDataReader, und das scheint gut für einfache Spritztouren durch eine wählen, aber ich fühle mich wie es kann einige andere Modelle lauern .Net, die sind nützlich, um zu lernen mehr über.Ich fühle mich wie all die Hilfe, die ich finden das einfach nur benutzt Datensatz mit Standardwert.Vielleicht und DataReader sind wirklich die besten Optionen.

Ich bin nicht auf der Suche für eine beste/Schlimmste Panne, nur neugierig, was meine Optionen sind und welche Erfahrungen haben Sie mit Ihnen hatte.Vielen Dank!

-Eric Sipple

Lösung

Da .NET 3.5 heraus kam, habe ich ausschließlich LINQ.Es ist wirklich so gut;Ich sehe keinen Grund, Sie zu verwenden, alle diese alten Krücken mehr.

So groß wie LINQ, aber ich denke, jeder ORM-system würde Ihnen erlauben, zu tun, Weg mit diesem dreck.

Andere Tipps

Wir haben uns Weg bewegt von datasets und bauen unser eigenes ORM-Objekte basierend auf CSLA.Sie können den gleichen job zu erledigen, die entweder mit einem DataSet oder LINQ oder ORM, sondern re-verwenden, es ist (die wir gefunden haben) viel einfacher."Weniger code machen glücklich'.

Ich war es satt mit DataSets in .Net 1.1, Sie wenigstens optimiert es so, dass es nicht langsamer als exponentiell für große Mengen nicht mehr.

Es war immer eine ziemlich aufgebläht Modell - habe ich nicht gesehen, viele apps verwenden die meisten seiner Funktionen.

SqlDataReader war gut, aber ich verwendet, um wickeln Sie es in eine IEnumerable<T> wo die T war einige typisierte Darstellung meiner Daten Zeile.

Linq ist eine weit bessere Ersatz meiner Meinung nach.

Ich habe mit dem Daten-Transfer-Objekte Muster (ursprünglich aus der Java-Welt, glaube ich), mit einem SqDataReader zu füllen Sammlungen von DTOs aus dem data layer für die Verwendung in anderen Ebenen der Anwendung.Die DTOs selbst sind sehr leicht und einfach Klassen aus Eigenschaften mit gets/sets.Sie können problemlos serialisiert/deserialisiert wird, und verwendet für databinding, wodurch Sie sehr gut geeignet, um die meisten meiner Entwicklung braucht.

Ich bin ein großer fan von SubSonic.Eine gut geschriebene batch/CMD-Datei erzeugen kann, die ein ganzes Objekt-Modell für Ihre Datenbank in Minuten;kompilieren Sie es in Ihrem eigenen DLL und verwenden Sie es als erforderlich.Wundervolles Modell, wunderbares Werkzeug.Die Website macht es klingen wie ein ASP.NET deal, aber im Allgemeinen funktioniert es auch wunderbar einfach überall, wenn Sie nicht versuchen, zu verwenden die UI-framework (was ich bin mäßig enttäuscht) oder dessen Anwendung-level-auto-generation-tools.

Für die Aufzeichnung, hier ist eine version der Befehl, den ich verwenden, um mit ihm zu arbeiten (so dass Sie nicht haben, um Kampf es zu hart anfänglich):

sonic.exe generate /server [servername] /db [dbname] /out [outputPathForCSfiles] /generatedNamespace [myNamespace] /useSPs true /removeUnderscores true

Das macht es jedes mal ...Dann erstellen Sie die DLL aus, dass Verzeichnis-dies ist Teil eines Projekt NAnt, abgefeuert von CruiseControl.NET -- und wir gehen Weg.Ich bin mit, dass in WinForms ASP.NET auch einige command-line utils.Dies erzeugt die wenigsten Abhängigkeiten und die größte "Portabilität" (zwischen verwandten Projekten, ZB).

Hinweis

Die oben ist jetzt gut ein Jahr alt.Während ich immer noch halten große Liebe in meinem Herzen für SubSonic, habe ich verschoben auf LINQ-to-SQL, wenn ich den Luxus haben, zu arbeiten .NET 3.5.In .NET 2.0, ich benutze immer noch im Unterschall.So ist meine neue offizielle Beratung ist Plattform-version abhängig.Im Fall von .NET 3+, gehen Sie mit der akzeptierten Antwort.Im Fall von .NET 2.0, gehen Sie mit SubSonic.

DataSets sind ideal für demos.

Ich würde nicht wissen, was zu tun mit einem, wenn Sie mich benutzen.

Ich benutze ObservableCollection

Dann wieder bin ich in der client-app-space, WPF und Silverlight.So übergeben Sie ein dataset oder datatable über ein service ist ...Brutto.

DataReaders sind schnell, da Sie nur vorwärts Strom der Ergebnismenge.

Ich habe verwendet typisierte und nicht typisierte DataSets, DataViewManagers, DataViews, DataTables, von DataRows, DataRowViews, und gerade über alles, was Sie tun können, mit dem stack, da es die Premieren kam in mehrere enterprise-Projekte.Es hat mich eine Weile zu gewöhnen, wie Sie ermöglichen es funktionierte.Ich habe geschrieben, benutzerdefinierte Komponenten und nutzt die Stapel als ADO.NETdid nicht ganz das, gib mir, was ich wirklich brauchte.Eine solche Komponente vergleicht DataSets und dann updates im backend speichert.Ich weiß wirklich, wie alle diese Elemente gut funktionieren, und diejenigen, die gesehen haben, was ich getan haben, sind sehr beeindruckt, dass ich es geschafft, darüber hinaus gibt es das Gefühl, dass es nur hilfreich für demo-Einsatz.

Ich benutze ADO.NET Bindung in Winforms und ich auch den code in der Konsole-apps.Ich habe kürzlich zusammen mit einem anderen Entwickler zum erstellen eines benutzerdefinierten ORM, dass wir gegen eine verrückte datamodel, dass wir gegeben wurden, von Auftragnehmern, sah nichts, wie unsere normalen Daten speichert.

Ich suchte heute für den Ersatz an ADO.NET und ich sehe nicht, nichts, was ich ernsthaft versuchen sollte, zu lernen, zu ersetzen, was ich derzeit verwenden.

Ich benutze Sie ausgiebig, aber ich glaube nicht, verwenden die "erweiterte" Funktionen, die Microsoft war wirklich drängt, wenn der Rahmen zum ersten mal aus.Ich bin im Grunde nur, Sie als Listen, Hashtabellen, die finde ich perfekt nützlich.

Ich habe nicht gesehen, gute Ergebnisse, wenn die Leute haben versucht, die komplexen typisierte DataSets oder versuchte sogar, die den Fremdschlüssel Beziehungen zwischen Tabellen mit Datensätzen.

Natürlich, ich bin einer von den seltsamen diejenigen, die eigentlich lieber ein DataRow-zu einer Entität-Objekt-Instanz.

Pre linq ich verwendet DataReader zum füllen der Liste meiner eigenen benutzerdefinierten domain-Objekte, sondern post linq ich habe mit L2S füllen L2S-Entitäten, oder L2S füllen domain-Objekte.

Sobald ich ein bisschen mehr Zeit, um zu untersuchen, vermute ich, dass Entity Framework-Objekte wird mein neues Lieblings-Lösung!

Die Auswahl einer modernen, stabilen und unterstützte aktiv ORM-tool ist wahrscheinlich die größte Steigerung der Produktivität nur etwa jedes Projekt, von mittlerer Größe und Komplexität bekommen können.Wenn Sie zu dem Schluss, dass Sie absolut, absolut, absolut haben zu schreiben Ihre eigenen DAL und ORM, sind Sie wahrscheinlich tun es falsch (oder du bist mit den weltweit meisten obskuren Datenbank).

Wenn Sie im raw-Datensätze und-Zeilen und was nicht, verbringen Sie den Tag, um zu versuchen, ein ORM, und Sie werden erstaunt sein, wie viel produktiver Sie sein können, w/o all die Plackerei der Zuordnung der Spalten, um Felder oder die ganze Zeit füllen Sql-Kommando-Objekte und alle anderen Reifen springen wir alle einmal durchgemacht haben.

Ich Liebe mich einige Subsonic, aber für kleinere Projekte zusammen mit demos/Prototypen, finde ich Linq to Sql verdammt nützlich erweisen.Ich hasse EF mit einer Leidenschaft, obwohl.:P

Ich habe typisierte DataSets für mehrere Projekte.Sie modellieren die Datenbank nun, erzwingen von Einschränkungen, die auf der client-Seite, und im Allgemeinen sind eine solide Daten-access-Technologie, vor allem mit den Veränderungen .NET 2.0 mit TableAdapters.

Typisierte DataSets bekommen einen schlechten rap von Menschen, die mag zu verwenden, emotionale Wörter wie "aufgebläht", um Sie zu beschreiben.Das gebe ich zu, dass ich, wie mit einer guten O/R-mapper-mehr als die Verwendung von DataSets;es ist nur "fühlt" sich besser mit Objekten und Sammlungen statt der typisierten DataTables, von DataRows, etc.Aber was ich gefunden habe ist, dass, wenn aus irgendeinem Grund Sie nicht können oder nicht wollen, zu verwenden eine O/R-mapper, typisierte DataSets sind eine gute Wahl, die einfach genug zu nutzen und erhalten Sie 90% von die Vorteile eines O/R-mapper.

EDIT:

Einige hier vorschlagen, dass DataReaders sind die "schnelle" alternative.Aber wenn Sie verwenden die Reflektor Blick auf die Interna eines DataAdapter (die Datentabellen sind gefüllt), Sie werden sehen, dass es benutzt...ein DataReader.Typisierte DataSets Mai haben einen größeren Speicherbedarf als andere Optionen, aber ich habe noch zu sehen, die Anwendung, wo dies macht einen spürbaren Unterschied.

Verwenden Sie das beste Werkzeug für den job.Don ' T machen Sie Ihre Entscheidung auf der Grundlage von emotionalen Wörtern wie "gross" oder "aufgebläht", die keine sachliche Grundlage.

I just build my business-Objekte von Grund auf, und fast nie verwenden Sie die DataTable-und vor allem nicht das DataSet nicht mehr, außer die, zunächst füllen Sie die business-Objekte.Die Vorteile für den Aufbau Ihrer eigenen Testbarkeit, Typsicherheit und intellisense, die Erweiterbarkeit (versuchen Sie, an ein DataSet) und Lesbarkeit (es sei denn, Sie genießen das Lesen Dinge wie "Konvertieren".ToDecimal(dt.Zeilen[i]["blah"].ToString())).

Wenn ich schlauer, ich würde auch eine ORM-und 3rd-party-DI-framework, aber nur noch nicht das Gefühl, die Notwendigkeit für diese.Ich mache viele kleinere Größe Projekten oder Ergänzungen zu größeren Projekten.

Ich habe NIE datasets.Sie sind große Schwergewichts-Objekte nutzbar (als jemand wies darauf hin, hier) für "demoware".Es gibt viele großartige alternativen, die hier gezeigt.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow