Dies ist eine Vereinfachung des Problems (es gibt viele Möglichkeiten, Dinge zu tun), aber unter den Anwendungen, die mit einer Datenbank sprechen müssen, habe ich normalerweise eines von zwei Mustern gesehen:
Einer der Hauptunterschiede zwischen den beiden Ansätzen ist, dass ORM Ihnen erlaubt, stark typisierte Felder in Ihrem Code wie folgt zu referenzieren:
%Vor%Bei der DataTable-Methode wäre Ihr Code etwa wie folgt:
%Vor%In diesem Fall profitiert der ORM-Ansatz von der Überprüfung der Kompilierungszeit, während dies beim DataTable-Ansatz nicht der Fall ist. Auf der anderen Seite sind die DataTable (und das DataSet) bereits geschriebene Datenstrukturen, die eine ausgezeichnete Arbeit zum direkten Darstellen von relationalen Daten leisten, so dass Code, der sie verwendet, in der Regel schneller implementiert werden kann. Darüber hinaus kann Code, der DataTables verwendet, leicht von anderen verstanden und geändert werden. Eigengewachsene (und oft COTS) ORM-Systeme tun häufig zusätzlichen Datenbankzugriff "unter der Haube", um Fremdschlüssel usw. zu füllen, was Probleme für Unwissene schaffen kann.
Welchen Ansatz favorisieren Sie generell und warum?
Datatable wird konzeptionell einfacher im Umgang mit Daten sein. Und es ist frei von manchmal unnatürlichen Redewendungen, die Sie in ORM finden. (Abfrage eines Datensatzes in den lokalen Speicher, vor der Aktualisierung; 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 wirklich keine SQL schreiben müssen, um grundlegende Crud zu tun. Natürlich müssen komplexere Anweisungen in einer weniger starken Subsprache (d. H. Hql) geschrieben werden
2) Der andere große Vorteil von ORM besteht darin, dass Sie, wenn Sie Ergebnisse erhalten, diese in Wertobjekte umwandeln, ohne eine Menge Code zu schreiben, um die Werte abzubilden und die Typkonvertierung durchzuführen.
Wenn Sie starke SQL-Kenntnisse haben, aber den Vorteil 2 haben wollen, würde ich mit ibatis
gehenIch favorisiere den DataTables-Weg, weil ich alt, müde und skeptisch gegenüber Moden wie Subsonic und Linq bin.
Wenn Sie darüber hinaus mit einem ORM arbeiten, minimieren Sie in der Regel, was Sie in SQL tun. Sie verwenden nicht viel Logik in der SQL-Datei, und Sie laden mehrere SQL-Anweisungen nicht zusammen, um mehrere Dinge in einer einzigen Reise in die Datenbank zu erledigen. Daher neigen Sie dazu, häufiger in die Datenbank zu gehen, und das ist ein großer Leistungshit.
Unter Verwendung von Datasets kann ich Folgendes tun:
wähle col1, col2 ... aus table1
wähle col1, col2 ... aus table2
wähle col1, col2 ... aus table3
und machen Sie dann einen Trip zur Datenbank, um alle drei DataSets zu erhalten, indem Sie Tabellen [0], Tabellen [1], Tabellen [2] verwenden, um sie zu referenzieren. Es macht einen sehr großen Unterschied in der Leistung.
Irgendwann wird die Interaktion mit der Datenbank vielleicht so schnell sein, dass es keinen Sinn macht, die SQL-Datenbank aufzuteilen, aber dieser Tag ist noch nicht da. Wenn es soweit ist, werde ich zu ORM wechseln, aber bis dahin bin ich bereit, meinen Code ein bisschen hässlicher gegen Leistung zu haben. Es macht keinen Spaß für Benutzer, eine langsame App zu verwenden.
Schließlich mag ich SQL. Ich bin gut in SQL. Echt gut. Ich möchte nicht meine Zeit damit verbringen herauszufinden, wie ich Linq dazu bringen kann, das SQL zu senden, das ich möchte. Es würde MY Leistung verlangsamen.
Sie können beide genannten Ansätze kombinieren, indem Sie stark typisierte DataSets verwenden.
Es ist möglich, sie zu einem Visual Studio-Projekt über den "Add New Item" -Dialog "DataSet-Vorlage" hinzuzufügen und dann Visual Dataset Designer zu verwenden (es editiert die XSD-Datei hinter den Kulissen).
Es gibt einen weiteren Artikel zum Thema.
In stark typisierten Datasets von .Net haben Sie die Vorteile, die Sie ORM zuweisen - den Wert der starken Typisierung in IDE und Intellisense,
Die TableAdapters, die in Visual Studio erstellt werden, werden alle Ihre CRUD SQL für Sie schreiben. Sie setzen Ihre Geschäftslogik in C # (oder eine andere Sprache) und nicht in SQL.
Ich denke, das von Datasets angebotene disconnected data model erweist sich in der Praxis als effizienter als typisches handcodiertes SQL. Dies führt zu nicht-gesprächigen DB-Interaktionen, bei denen Sie alle zugehörigen Tabellendaten in einer einzigen Abfrage erhalten. Und es hat eine sehr gute Unterstützung für optimistisches Sperren (DBConcurrency-Ausnahmen bereitstellen). Das Dataset verfolgt außerdem Einfügungen, Änderungen und Löschungen Ihrer Daten, sodass Sie dies nicht tun müssen.
Stark typisierte Datensätze bieten auch direkte Navigation zu verwandten Tabellendaten.
Eine gute Referenz auf DataSets ist
Programmieren von Microsoft® ADO.NET 2.0 Core Referenz von David Sceppa
Herausgeber: Microsoft Press Pub Datum: 17. Mai 2006 Druck ISBN-10: 0-7356-2206-X Druck ISBN-13: 978-0-7356-2206-7 Seiten: 800
+ tom
Ich würde mir die Vorteile von Datenobjekten gegenüber DataTables ansehen (eine phantastische ORM-Bibliothek ist nicht wirklich notwendig, obwohl sie nett sein kann):
Transformieren Sie die Daten nur einmal. In den DataTable-Crunching-Apps, die ich gesehen habe, gibt es eine Menge davon verstreut:
if (row ["col"] == DBNull.Value || string.IsNullOrEmpty (row ["col"] als String)) ...
Ich würde diese Bedingung lieber einmal überprüfen, wenn ich das Datenobjekt bevölkere, anstatt es überall dort zu überprüfen, wo die DataTable verwendet wird.
Ich glaube, ORM kann dich faul machen. Zum Beispiel gibt es absolut keinen Grund, einen Satz verwandter Datenobjekte aus einzelnen Abfragen in den Objekten zu füllen, wenn diese Objekte immer zusammen verwendet werden. Schreiben Sie stattdessen eine große und effiziente Abfrage, die alle erforderlichen Daten erfasst und dann das Datenobjektdiagramm erstellt. Dennoch, wenn Sie seine Einschränkungen beachten, spart es eine Menge Arbeit.
Ich habe DataSets in frühen .NET-Tagen verwendet und dann typisierte DataSets verwendet. Im Laufe der Zeit stellte sich heraus, dass der von DataSets hinterlassene Speicherbedarf sehr hoch ist und es nicht sinnvoll war, nicht verwaltete Objekte für einfache Aufgaben zu verwenden.
Daraus wurde geschlossen, dass DTOs / POCOs eine bessere Wahl sind und begannen, NHibernate und iBatis zu verwenden.
Meine durchschnittlichen (oder unterdurchschnittlichen) Entwickler fanden sie komplex und schwer zu benutzen (kein Wortspiel beabsichtigt).
So machte ich ein home ORM XmlDataMapper , das war viel einfacher zu verwenden, dass die komplexen ORMs da draußen.
Um XmlDataMapper zu integrieren, müssen Sie nur 4 kleine Schritte machen
Früher habe ich nur einen Datenreader benutzt, um Felder mit GetString, GetInt usw. auf mein Objekt zu lesen, aber ich habe mich jetzt zu einem viel mehr OO und testbaren Ansatz bewegt, der ein Gateway verwendet, um eine Datentabelle von einer Abfrage zurückzugeben dann in eine Service-Klasse übergeben, die die Tabelle auf ein Objekt analysiert.
Ich mochte ORM-Tools nie wirklich, sie waren immer schwerfällig und schwer zu warten, aber ich hatte noch keine Gelegenheit, mit LINQ zu spielen, aber meine Meinung könnte sich ändern.
Ich finde, dass ich weniger Code entwickeln und meinen Code besser mit einem ORM als DataSets / DataTables testen kann. Ich verwende LINQ-to-SQL und wickle eine dünne Schicht um den vom Designer generierten Code über partielle Klassen wie mein ORM. Die Thin Layer erlaubt mir grundsätzlich einige rollenbasierte Berechtigungen hinzuzufügen und erhöht die Testbarkeit des Codes durch Refactoring auf Schnittstellen und die Verwendung von Dependency Injection um den Datenkontext anzugeben (auf diese Weise kann ich ihn für andere Tests abbilden).
Ich habe beides gemacht - schreibe mein eigenes ORM um DS / DT, stark typisiertes DS / DT, usw. und bin zu LINQ gewechselt und gehe nicht mehr zurück. Ich werde vielleicht zu etwas wie NHibernate, Entity Framework oder etwas anderem wechseln, aber im Moment bietet meine LINQ-Lösung so ziemlich alles, was ich brauche, und ist viel einfacher als meine alten Lösungen.