Ist ORM ein Anti-Pattern? [geschlossen]

Ich hatte eine sehr anregende und interessante Diskussion mit einem Kollegen über ORM und seine Vor- und Nachteile. Meiner Meinung nach ist ein ORM nur in den seltensten Fällen nützlich. Zumindest nach meiner Erfahrung.

Aber ich möchte meine eigenen Argumente derzeit nicht auflisten. Also frage ich dich, was denkst du über ORM? Was sind die Vor- und Nachteile?

Bei dem Versuch, eine relationale Datenbank von einem objektorientierten Standpunkt aus zu betrachten, gibt es eine relativ große und vielfältige Menge konzeptioneller und technischer Schwierigkeiten. Diese Schwierigkeiten werden zusammenfassend als objektrelationale Impedanzinkongruenz bezeichnet, und der zugehörige Wikipedia-Artikel ist äußerst informativ. Der Artikel nennt einige, ich sehe keinen vernünftigen Weg, sie hier zu beschreiben. Um Ihnen eine allgemeine Vorstellung zu geben, sind sie wie folgt katalogisiert:

• Fehlpaarungen
  • Objektorientierte Konzepte
  • Datentypunterschiede
  • Strukturelle und Integritätsunterschiede
  • Manipulative Unterschiede
  • Transaktionsunterschiede
• Beheben von Impedanzfehlanpassungen
  • Minimierung
  • Alternative Architekturen
  • Vergütung
• Streit
• Philosophische Unterschiede

Ich denke, wenn Sie sich die Zeit nehmen, den Artikel zu lesen, werden Sie verstehen, dass die Tatsache, dass ORM manchmal als Anti-Pattern beschrieben wird, in der Tat unvermeidlich ist. Die beiden Domänen sind so unterschiedlich, dass jeder Ansatz, eine Domäne wie die andere zu behandeln, standardmäßig ein Anti-Muster ist, in dem Sinne, dass ein Anti-Muster ein Muster ist, das gegen die Philosophie einer Domäne verstößt.

Aber ich denke nicht, dass der Begriff für irgendetwas gelten sollte, das im Wesentlichen als Brücke zwischen zwei sehr unterschiedlichen Domänen fungiert. Das Beschriften eines Musters als Anti-Muster ist nur innerhalb seiner Domäne sinnvoll. Die Frage, ob es sich um ein Anti-Pattern handelt oder nicht, spielt also keine Rolle.

Aber ist es nützlich? Ja, ORM ist eines der nützlichsten Anti-Patterns. Sie werden verstehen, warum nur, wenn Sie sich in einer praktischen Situation befinden, in der Sie Datenbanken in einem Projekt austauschen müssen. Oder sogar ein Upgrade auf eine andere Version derselben Datenbank. ORM ist eines dieser Dinge, die Sie nur dann vollständig verstehen, wenn Sie sie tatsächlich benötigen.

Natürlich ist ORM, wie alles Nützliche, sehr anfällig für Missbrauch. Wenn Sie der Meinung sind, dass es die Notwendigkeit ersetzt, alles über die Datenbank zu wissen, an der Sie arbeiten, wird es zurückkommen und Sie beißen. Hart.

Lassen Sie mich zum Schluss noch eine meiner Antworten schamlos in das verwandte Thema "Entspricht / fördert das ActiveRecord-Muster den SOLID-Entwurfsprinzipien?" Einfügen. Frage, die für mich eine weitaus relevantere Frage ist als "ist es ein Anti-Muster".

Dies ist vergleichbar mit der Frage "Ist eine Bohrmaschine ein Anti-Pattern?". ORMs haben sich einen guten Platz in meiner Toolbox erarbeitet und meinen Boilerplate-Code reduziert. Bei Bedarf kann ich weiterhin benutzerdefiniertes SQL verwenden. Also, wenn es ein Anti-Muster ist, gegen welches Muster geht es?

Meine Antwort lautet: Nein, es gibt viele ausgereifte ORMs, die Ihnen das Leben erheblich erleichtern und Ihren Code verständlicher machen. Dies bedeutet in keiner Weise, dass Sie SQL verstehen müssen, ganz im Gegenteil.

Ich würde es hegen, etwas als "Anti-Pattern" zu bezeichnen, das zuerst von Martin Fowler als Pattern bezeichnet wurde und seitdem in fast jeder modernen Programmiersprache verwendet wird. (Siehe den Wikipedia-Artikel zu ActiveRecord .)

Ein guter ORM kann zu viel weniger Code (und viel weniger Wiederholungen) in einem Projekt führen, und nichts ist so stark mit Fehlern korreliert wie die Menge des ursprünglichen Codes.

ORMs sind im Allgemeinen so konzipiert, dass sie die häufigsten Anwendungsfälle für die Arbeit mit Datenbanken verarbeiten. Komplexe Abfragen müssen möglicherweise noch explizit geschrieben werden. Es wird jedoch dringend empfohlen, für jede Datenbankinteraktion explizite Abfragen zu schreiben. In den meisten Fällen ist das Zeitverschwendung.

Ein ORM zu verwenden, anstatt SQL zu lernen, ist eine ziemlich schlechte Idee. Wenn Sie nicht genau wissen, welche Art von SQL generiert wird, wenn Sie die N + 1-Probleme nicht verstehen und nicht wissen, wie Sie optimieren können, wird dies definitiv mehr schaden als nützen. Ich habe jedoch das Gefühl, dass ich mit einem ORM viel produktiver bin. Ich bevorzuge Rails ActiveRecord, das nicht vorgibt, keine Datenbank zu haben, und sich nicht in die Quere kommt, wenn Sie nur SQL schreiben müssen. Ich mache mir allerdings Sorgen, dass manche Menschen den Redewendungen vertrauen, die sie zu tief sehen, ohne ein tiefes Verständnis dafür zu haben, was sie tun.

Meine Erfahrung: Ich verwende NHibernate mit Linq2NHibernate.

Vorteile:

• Es beseitigt "Magic Strings" oder bietet zumindest einen einmaligen Platz, um sie zu platzieren
• Es erlaubt mir, die ganze Zeit in einem OO-Paradigma zu arbeiten
• Der Code ist leichter zu lesen
• Der darauf aufbauende Code ist einfacher zu ändern
• Es ermöglicht Ihnen, Ihre aktuelle relationale Datenbank auszutauschen, ohne 2 separate Repositorys zu verwalten (dies ist selten der Fall, aber das ist ein großer Vorteil, wenn Sie es benötigen).

Nachteile:

• Der Code ist schwieriger zu schreiben , weil
• Es ist keine ausreichende Abstraktion - Sie müssen immer noch genau wissen, was es im Hintergrund tut

Ich werde sagen, dass es nicht das Versprechen erfüllt, auf das die meisten Menschen zunächst hoffen. Ich würde niemandem die Schuld dafür geben, dass es ein Anti-Pattern ist. In meinem Fall muss ich noch Integrationstests für eine SQLite-Datenbank durchführen, um sicherzustellen, dass meine Linq2NHibernate-Abfragen tatsächlich funktionieren. Wenn Sie also ohnehin Integrationstests für eine echte relationale Datenbank durchführen, wird das Problem mit "magischen Zeichenfolgen" auf diese Weise beseitigt.

Wenn ich ein neues Projekt starten würde, wäre ich mir nicht sicher, ob ich ein ORM verwenden würde oder nicht. Ich würde wahrscheinlich, aber ich kann nicht sicher sagen, ob Sie sollten. Ich würde sagen, es ist wie der Unterschied zwischen der Auswahl von C ++ oder Java / .NET für Ihr Projekt: Werden Sie die Flexibilität benötigen, die Sie bei der Arbeit auf einer niedrigeren Ebene erhalten, oder möchten Sie lieber auf einer höheren Ebene arbeiten und (angeblich) mehr produktiv? Die normale Antwort ist, so hoch wie möglich zu arbeiten . Das bedeutet normalerweise die Verwendung eines ORM.

Die Stärke eines ORM besteht darin, dass Sie das Anwendungsverhalten mithilfe objektorientierter Techniken modellieren können. In einer sorgfältig entwickelten Welt haben Sie eine Anwendungsebene, in der die Geschäftssprache genau mit der Sprache des Entwicklungsteams übereinstimmt. Der ORM ist ein Enabler davon, wenn der ORM vernünftig verwendet wird.

Die Schwäche ist, dass die Anzahl der Leute, die tatsächlich wirklich objektorientiertes Programmieren bekommen, ziemlich klein ist. Viele Leute schreiben Spaghetti und Frikadellen mit stark gekoppelten Objekten, die sich nur wenig verhalten und das tatsächliche Verhalten in abscheulichen 8000-Zeilen-Klassen "Service" und "Manager" enden, und dieser Code ist oft so verwickelt, dass jeder Angst hat es zu ändern, weil sie nicht herausfinden können, was die Nebenwirkungen sein werden.

Darüber hinaus verstehen viele Menschen das relationale Modell nicht wirklich. Ein ORM wird ihnen nicht helfen, es zu bekommen, und es wird ihnen nicht helfen, indem es das relationale Modell abstrahiert. Sie können sich einfach frühzeitig auf Ihre Domain-Ebene konzentrieren und dies tun, bevor Sie sich zu sehr mit dem Datenbank-Design befassen. Wenn es richtig angewendet wird, können Sie mithilfe vernünftiger Schemamigrations-Tools und ORM verhindern, dass sich Code-Schulden ansammeln.

Ich habe Anwendungen erstellt, in denen ein ORM den Anwendungscode einfach, lesbar und testbar hielt und eine angemessene Leistung aufwies. Ich habe auch Anwendungen gepflegt, bei denen das Muster missbraucht und der Code verschlungen, nicht testbar, langsam und zerbrechlich war. Es stellte sich heraus, dass der ORM selbst wenig damit zu tun hatte, außer dass das ältere Entwicklungsteam keinen fehlerhaften Code schrieb, der die Anwendungsdomäne schlecht modellierte, und keinen fehlerhaften Service-Layer-Code, der alles vernachlässigte der Wert, den ihr ORM ihnen bieten könnte.

ORMs werden Sie nicht schlauer machen, aber in den Händen des richtigen Entwicklers können sie zu besser wartbarem und qualitativ höherem Code führen.

Vielleicht liegt die Antwort in der Umkehrung Ihrer Frage: Ist Ihre Anwendungsdaten in etwas Speicherung andere als eine relationale Datenbank eine gute Idee? Welche Probleme beseitigen Sie und welche anderen Probleme werden Sie aufgreifen? Können Sie ohne die Möglichkeit auskommen, auf einfache Weise Querverweise zu Ihren Daten (Joins) zu erstellen oder die gewünschten Datensätze anhand mehrerer Kriterien schnell herauszufiltern? Benötigen Sie keine solide Transaktionsunterstützung (vorausgesetzt, Ihre Alternative hat keine)? Nicht alle Anwendungen benötigen einen immer konsistenten und vollständigen Datenspeicher.

Ich denke, das wirkliche Anti-Pattern hier ist die Verwendung einer relationalen Datenbank, wenn Sie keine benötigen. Wenn Sie eines brauchen, brauchen Sie ORM, und es ist definitiv kein Anti-Pattern.

ORM ist ein Werkzeug. Wie alle Werkzeuge funktionieren sie bei sachgemäßer Verwendung recht gut. Bei unsachgemäßer Verwendung sind ein größerer Hammer und etwas Klebeband erforderlich.

Im Falle des aktuellen Projekts, an dem ich arbeite, wird es von Nicht-Entwicklern (Maschinenbauingenieuren, um genau zu sein) gepflegt und muss daher einfach und leicht herauszufinden sein. Es wird einige Jahre dauern, bis diese Gruppe ein Budget für die Einstellung von Entwicklern hat (vorausgesetzt, der nächste Präsident hebt die betreffende Agentur nicht auf). Daher spielen die zukünftigen Wartungsfunktionen eine wichtige Rolle bei unseren Überlegungen.