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 verwendete DataSets in frühen .NET-Tagen, dann begann mit typisierten DataSets, im Laufe der Zeit gefunden, dass der Speicher-Fußabdruck von DataSets links sehr hoch sind und es nicht sinnvoll, unmanaged Objekte für jede einfache Aufgaben zu verwenden.
Daher kam ich zu dem Schluss, dass DTOs/POCOs die bessere Wahl sind und begann mit NHibernate und iBatis.
Meine durchschnittlichen (oder unterdurchschnittlichen) Entwickler fanden sie komplex und schwer zu bedienen (kein Wortspiel beabsichtigt).
Also habe ich eine selbst angebaut ORM XmlDataMapper die viel einfacher zu benutzen war als die komplexen ORMs, die es gibt.

Um XmlDataMapper zu integrieren, müssen Sie nur 4 kleine Schritte tun

1. Erstellen Sie eine Business-Entität / DTO für die Tabellen
2. Erstellen Sie eine XML-Datei mit den Zuordnungsinformationen zwischen der Tabelle und dem DTO.
3. Geben Sie das DTO und die xml-Datei in der Konfiguration an.
4. Rufen Sie einfach DTOConverter.Convert(dataReader) und andere Methoden dieser Art auf, um Ihren Datenbankdatensatz in ein DTO / Business Entity zu konvertieren

Answer 2

Ich verwendet, um nur einen Datareader, um Felder auf mein Objekt mit GetString, GetInt usw. zu lesen, aber ich habe jetzt auf eine viel mehr OO und testbare Ansatz mit einem Gateway, um eine datatable aus einer Abfrage zurückgeben, dies wird dann in eine Serviceklasse übergeben, die die Tabelle auf ein Objekt parst bewegt.

Ich mochte nie wirklich ORM-Tools, sie waren immer umständlich und schwer zu pflegen, aber ich hatte noch keine Gelegenheit, mit LINQ zu spielen, also kann sich meine Meinung ändern.

Answer 3

Ich finde, dass ich in der Lage bin, weniger Code zu entwickeln und meinen Code besser mit einem ORM als DataSets/DataTables zu testen. Ich verwende derzeit LINQ-to-SQL und wickle eine dünne Schicht um den vom Designer generierten Code über partielle Klassen als mein ORM. Die dünne Schicht ermöglicht es mir im Grunde, einige rollenbasierte Berechtigungen hinzuzufügen und erhöht die Testbarkeit des Codes durch Refactoring auf Schnittstellen und mithilfe von Dependency Injection, um den Datenkontext zu spezifizieren (auf diese Weise kann ich es für andere Tests nachbilden).

Ich habe beides getan - schreiben Sie meine eigenen ORM um DS/DT, stark getypten DS/DT, etc. und haben zu LINQ gewechselt und bin nicht zurück gehen. Ich kann schließlich zu etwas wie NHibernate, Entity Framework oder etwas anderes bewegen, aber für jetzt meine LINQ-Lösung bietet so ziemlich alles, was ich brauche und ist viel einfacher als meine alten Lösungen.