ASP.NET DataSet vs Business Objects/ORM

Question

Ich denke über Datenzugriff für eine ASP.NET-Anwendung nach. Von einer Firma kommend, die viele Windows-Anwendungen mit Client-Datensätzen verwendet, gibt es eine natürliche Abhängigkeit von einem DataSet-Ansatz für den Umgang mit Daten.

Ich bin mehr auf einen Business-Objekt-Ansatz und ich mag nicht die Idee, ein DataSet in der Sitzung zwischenspeichern und dann ein Update anwenden.

Hat jemand Erfahrung/Hilfe, um über die Vor- und Nachteile beider Ansätze zu vermitteln?

Answer 1

Sie sind klug, daran zu denken, eine Datenschicht in Ihrer App zu entwerfen. In einer ASP.NET-Anwendung wird dies Ihnen helfen, Ihren Datenzugriff zu standardisieren und erheblich zu vereinfachen. Sie müssen lernen, wie Sie ObjectDataSources erstellen und verwenden, aber das ist ziemlich einfach.

Der andere Vorteil einer Datenzugriffsebene (die mit einem separaten Projekt/DLL erstellt wurde) besteht darin, dass das Komponententest wesentlich vereinfacht wird. Ich würde Sie auch ermutigen, eine Business-Schicht zu erstellen, um einen Großteil der Datenverarbeitung zu erledigen (die Business-Schicht zum Beispiel wäre dafür verantwortlich, ObjectDataSources von der DAL in den UI-Code zu ziehen). Dadurch können Sie nicht nur Ihre Geschäftslogik kapseln, sondern auch die Testbarkeit des Codes verbessern.

Sie tun nicht wollen DataSets (oder DAL-Objekte, in dieser Angelegenheit) in der Sitzung Caching! Sie erstellen eine Web-App, sodass Datensatzänderungen eine eindeutige ID (oder eine andere Primärschlüsselspezifikation) verarbeiten und Änderungen direkt an die DAL weiterleiten, sobald sie vorgenommen werden. Wenn Sie alles zwischenspeichern würden, würden Sie dramatisch reduzieren die Skalierbarkeit Ihrer App.

Update: Andere in diesem Thread fördern die Idee der Verwendung von ORMs. Ich wäre vorsichtig bei der Übernahme eines vollwertigen ORM aus Gründen, die ich zuvor beschrieben habe here und here. I do stimme jedoch zu, dass es ratsam wäre, DataSets zu vermeiden. In meiner eigenen Arbeit benutze ich umfassend DataReaders, um meine ObjectDataSources zu füllen (was aufgrund des Designs meiner DAL trivial ist) und finde es sehr effizient.

Answer 2

Wenn Sie der Richtung von Microsoft folgen, dann geht der Trend definitiv zu LINQ (ORM) vs. DataSets. Als DataSets ins Leben gerufen wurde (ASP.NET 1.0), war LINQ nicht einmal möglich. Mit LINQ erhalten Sie Typ-Sicherheit und eingebaute Funktionen zum Erstellen/Aktualisieren/Löschen von der Datenbank.

Microsoft hat sogar versucht, den Übergang durch LINQ to DataSet einfacher zu machen.

Answer 3

DataSets können im Vergleich zu anderen ADO.NET-Objekten wie DataReadern unglaublich ineffizient sein. Ich würde vorschlagen, in Richtung der BO/ORM-Route zu gehen, basierend auf dem, was Sie sagen.

Answer 4

Wir sind dabei, ein großes Update für eine vorhandene ASP-App zu erstellen, die DataSet-Objekte stark verwendet. Obwohl ich mich nicht auf den Schmerz freue, werde ich darauf bestehen, die BO-Route hinunter zu gehen. Allein der Gedanke, die Datensätze jetzt zum Laufen zu bringen, bringt mich zum Schwitzen.

Ich denke, wir werden die LINQ Route gehen und leichte Entity-Objekte verwenden.

Answer 5

Das Unternehmen, in dem ich arbeite, verwendet auch DataSets, während es auch eine Business-Schicht gibt. BL lädt hauptsächlich Datensätze aus der DB.

Ich persönlich mag diesen Ansatz nicht.Es gibt auch eine Praxis, die Datensätze nach dem Laden/vor dem Speichern direkt zu modifizieren, um einige unmittelbare Bedürfnisse hier und dort zu erfüllen. Für mich verstößt es wirklich gegen die Idee von Geschäftsobjekten, aber so wird es gemacht.

ORM-Frameworks können Ihnen sehr viel Zeit sparen, besonders in Unternehmensanwendungen mit vielen Ansichten mit ähnlichen Schaltflächen und Operationen.

Aber es ist auch leicht, die Kontrolle zu verlieren. Seit diesem Zeitpunkt wird es langsam ein Chaos werden.

Beide Optionen sind gut, wenn sie in richtigen Fällen verwendet werden. Misch sie einfach nicht zusammen. Entscheide dich, es auf eine Art zu machen und folge ihm.

Answer 6

Mark Brittinghams Antwort ist genau für zweistufige Anwendungen. Aber was, wenn ich eine Service-Ebene verwenden möchte. DataSets sind serialisierbar. Getippte DataSets sparen Zeit beim manuellen Codieren Ihrer eigenen Objekte. Typisierte DataSets sind erweiterbar. Linq to Entities hat Performance-Probleme, Linq to SQL ist jetzt tot. Linq to DataSet wird immer eine Option sein.

Ich werde typisierte DataSets und eine vielschichtige Architektur verwenden, um Zeit zu sparen und Code zu organisieren. Ich habe handcodierte BOs ausprobiert und die zusätzliche Zeit und Wartungszeit ist es nicht wert.