Eigenentwickeltes ORM vs. DataTables?

Question

Dies ist eine Vereinfachung des Problems (es gibt viele Möglichkeiten, Dinge zu tun), aber bei Anwendungen, die mit einer Datenbank kommunizieren müssen, habe ich normalerweise eines von zwei Mustern gesehen:

1. Objekt-Relationales Mapping (ORM), bei dem (in der Regel) jede Tabelle in der Datenbank eine entsprechende "Row-Wrapper"-Klasse mit öffentlichen Eigenschaften hat, die den Spalten der Tabelle entsprechen. Manchmal rufen diese Klassen auch automatisch verwandte Informationen ab, so dass Fremdschlüsselspalten stattdessen als verwandte Daten (und nicht nur als PK-Werte) angezeigt werden können.
2. DataTables (und/oder DataSets), bei denen die Daten als DataTable vom Server abgerufen und in dieser Form bearbeitet werden (auch in der Benutzeroberfläche).

Einer der Hauptunterschiede zwischen den beiden Ansätzen ist, dass ORM es Ihnen ermöglicht, in Ihrem Code auf stark typisierte Felder zu verweisen:

Person bob = new Person();
bob.FirstName = "Bob";
collectionPeople.Add(bob);

Mit dem DataTable-Ansatz hingegen würde Ihr Code etwa so aussehen:

DataRow newrow = datatablePeople.NewRow();
newrow["FirstName"] = "Bob";
datatablePeople.Rows.Add(newrow);

In diesem Fall profitiert der ORM-Ansatz von der Kompilierzeitüberprüfung, während der DataTable-Ansatz dies nicht tut. Andererseits handelt es sich bei DataTable (und DataSet) um bereits geschriebene Datenstrukturen, die relationale Daten sehr gut direkt darstellen können. Darüber hinaus kann Code, der DataTables verwendet, von anderen leicht verstanden und geändert werden. Eigene ORM-Systeme (und oft auch COTS-Systeme) führen oft zusätzliche Datenbankzugriffe "unter der Haube" durch, um Fremdschlüssel usw. aufzufüllen, was für Unwissende zu Problemen führen kann.

Welchen Ansatz bevorzugen Sie also im Allgemeinen und warum?

Answer 1

Ich bevorzuge den DataTables-Weg, denn ich bin alt, müde und skeptisch gegenüber Moden wie Subsonic und Linq.

Wenn Sie mit einem ORM arbeiten, minimieren Sie darüber hinaus im Allgemeinen Ihre SQL-Aktivitäten. Sie fügen nicht viel Logik in die SQL-Anweisungen ein, und Sie fassen nicht mehrere SQL-Anweisungen zusammen, um mehrere Dinge auf einmal in der Datenbank zu erledigen. Daher müssen Sie die Datenbank häufiger aufrufen, was sich negativ auf die Leistung auswirkt.

Mit Datasets kann ich so etwas tun wie:

select col1, col2... from table1
select col1, col2... from table2
select col1, col2... from table3

und dann EINE Reise in die Datenbank machen, um alle drei DataSets zu erhalten, mit Tables[0], Tables[1], Tables[2], um sie zu referenzieren. Das macht einen sehr großen Unterschied in der Leistung.

Eines Tages wird die Interaktion mit der Datenbank vielleicht so schnell sein, dass es keinen Sinn mehr macht, SQL zu bündeln, aber dieser Tag ist noch nicht gekommen. Wenn es soweit ist, werde ich auf ORM umsteigen, aber bis dahin bin ich bereit, meinen Code im Austausch für die Leistung etwas hässlicher zu gestalten. Es macht den Benutzern keinen Spaß, eine träge Anwendung zu benutzen.

Schließlich mag ich SQL. Ich bin gut in SQL. Wirklich gut. Ich möchte meine Zeit nicht damit verbringen, herauszufinden, wie ich Linq dazu bringen kann, das von mir gewünschte SQL auszugeben. Das würde die Arbeit verlangsamen MEIN Leistung.

Answer 2

Datatable ist sicherlich konzeptionell einfacher in der Arbeit mit Daten. Und es ist frei von den manchmal unnatürlichen Idiomen, die man in ORM findet. (Abfrage eines Datensatzes im lokalen Speicher, bevor er aktualisiert wird; Joins sind Zeiger; der Schlüsselwert selbst ist ein Zeiger, daher erfordert das Hinzufügen eines Datensatzes das Laden des übergeordneten Datensatzes)

Die großen Vorteile für ORM sind...

1) Es schreibt die Sql für Sie, so dass Sie nicht wirklich eine Sql schreiben müssen, um grundlegende Dinge zu tun. Komplexere Anweisungen müssen natürlich in einer weniger leistungsfähigen Untersprache (z. B. hql) geschrieben werden.

2) Der andere große Vorteil von ORM ist, wenn Sie Ergebnisse zurückbekommen, mappt es in Wertobjekte, ohne einen Haufen Code zu schreiben, um die Werte zu mappen und Typkonvertierung zu behandeln.

Wenn Sie starke Sql-Kenntnisse haben, aber Vorteil 2 abgedeckt haben wollen, würde ich mit ibatis gehen

Answer 3

Sie können beide genannten Ansätze kombinieren, indem Sie Stark typisierte Datensätze .

Es ist möglich, sie zu einem Visual Studio Projekt über "Add New Item" Dialog "DataSet template" hinzuzufügen und dann den Visual Dataset Designer zu verwenden (er bearbeitet die XSD-Datei im Hintergrund).

Es gibt eine weitere Artikel zum Thema.

Answer 4

In .Net haben stark typisierte Datasets die Vorteile, die Sie ORM zuschreiben - den Wert der starken Typisierung in der IDE und Intellisense,

Die in Visual Studio erstellten TableAdapter schreiben das gesamte CRUD-SQL für Sie. Sie schreiben Ihre Geschäftslogik in C# (oder einer anderen Sprache) und nicht in SQL.

Ich denke, dass das unverbundene Datenmodell, das Datensätze bieten, sich in der Praxis als effizienter erweist als typisches handcodiertes SQL. Es führt zu nicht-schwätzerischen DB-Interaktionen, bei denen Sie alle Daten Ihrer Bezugstabellen in einer einzigen Abfrage erhalten. Außerdem bietet es sehr gute Unterstützung für optimistisches Sperren (mit DBConcurrency-Ausnahmen). Das Dataset verfolgt auch Einfügungen, Änderungen und Löschungen Ihrer Daten, so dass Sie das nicht tun müssen.

Stark typisierte Datensätze bieten auch eine einfache Navigation zu verwandten Tabellendaten.

Eine gute Referenz über DataSets ist

Programmierung von Microsoft® ADO.NET 2.0 Kernreferenz von David Sceppa

Herausgeber: Microsoft Press Erscheinungsdatum: Mai 17, 2006 Print ISBN-10: 0-7356-2206-X Drucken ISBN-13: 978-0-7356-2206-7 Seiten: 800

+tom

Answer 5

Ich würde mir die Vorteile von Datenobjekten gegenüber DataTables ansehen (eine ausgefallene ORM-Bibliothek ist nicht wirklich notwendig, obwohl sie nett sein kann):

• Konzeptionell sauber. Sie sind gezwungen, OO-Konzepte auf Ihre Daten anzuwenden. Es ist einfacher zu verstehen: "Dies ist eine Person" im Gegensatz zu "Die Person, die ich suche, ist irgendwo in dieser Tabelle".

• Erzwingt die Trennung der Interessen. Es ist verlockend, UI-Kontextdaten an eine DataTable anzuhängen - für eine UI erhalte ich eine Person mit einer primären Adresse im selben Datensatz, für eine andere eine Person mit Kreditinformationen im selben Datensatz. Wenn ich mit einem Modell arbeite, möchte ich, dass dieses Modell konsistent ist, egal wo ich es verwende.

• Transformieren Sie die Daten nur einmal. In den DataTable-crunching-Anwendungen, die ich gesehen habe, gibt es eine Menge von diesem überall verstreut:

  if(row["col"] == DBNull.Value || string.IsNullOrEmpty(row["col"] as string)) ...

  Ich würde lieber überprüfen, dass Bedingung einmal, wenn ich das Datenobjekt gegenüber Überprüfung es überall die DataTable verwendet wird.

• Leichtere Unit-Tests. Wenn Sie auf ein Feld in einem Datenobjekt verweisen, das nicht existiert, erhalten Sie einen Kompilierfehler. Wenn Sie auf ein Feld in einer DataTable verweisen, das nicht existiert, erhalten Sie einen Laufzeitfehler.

Ich glaube, ORM kann einen faul machen. Es gibt zum Beispiel absolut keinen Grund, einen Satz zusammengehöriger Datenobjekte aus einzelnen Abfragen in den Objekten aufzufüllen, wenn diese Objekte immer zusammen verwendet werden. Schreiben Sie stattdessen eine große und effiziente Abfrage, die alle erforderlichen Daten abruft und dann den Datenobjektgraphen aufbaut. Wenn Sie jedoch die Einschränkungen beachten, spart dies eine Menge Arbeit.

Verwandt: Wie kann ich meine Kollegen davon überzeugen, keine Datasets für die Unternehmensentwicklung (.NET 2.0+) zu verwenden? .