it-swarm-eu.dev

Ist ORM ein Anti-Pattern?

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 derzeit keine eigenen Argumente auflisten. Also frage ich dich, was denkst du über ORM? Was sind die Vor- und Nachteile?

58
derphil

Es gibt eine ziemlich große und vielfältige Reihe konzeptioneller und technischer Schwierigkeiten, wenn versucht wird, eine relationale Datenbank aus einem objektorientierten Blickwinkel zu betrachten. Diese Schwierigkeiten werden zusammen als objektrelationale Impedanzfehlanpassung bezeichnet, und der verwandter Wikipedia-Artikel ist äußerst informativ. Der Artikel identifiziert einige, ich sehe keine vernünftige Art, sie hier zu beschreiben. Um Ihnen eine allgemeine Vorstellung zu geben, werden 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-Muster beschrieben wird, tatsächlich unvermeidlich ist. Die beiden Domänen sind so unterschiedlich, dass jeder Ansatz, eine als 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.

Ich denke jedoch nicht, dass der Begriff für irgendetwas gelten sollte, das im Wesentlichen als Brücke zwischen zwei sehr unterschiedlichen Bereichen fungiert. Das Kennzeichnen 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 da draußen. Sie werden verstehen, warum nur, wenn Sie sich in einer praktischen Situation befinden, in der Sie Datenbanken in einem Projekt austauschen müssen. Oder aktualisieren Sie 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 dies die Notwendigkeit ersetzt, alles über die Datenbank zu wissen, an der Sie arbeiten, wird es zurückkommen und Sie beißen. Schwer.

Lassen Sie mich zum Schluss schamlos eine andere meiner Antworten auf das verwandte "Folgt/fördert das ActiveRecord-Muster die SOLID Designprinzipien?" Frage, die für mich eine weitaus relevantere Frage ist als "ist es ein Anti-Muster".

84
yannis

Dies ist vergleichbar mit der Frage "Ist eine Bohrmaschine ein Anti-Muster?". ORMs haben sich einen guten Platz in meiner Toolbox verdient 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 nicht verstehen müssen, ganz im Gegenteil.

42
Otávio Décio

Ich würde zögern, 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 der Wikipedia-Artikel zu ActiveRecord .)

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

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

18
Nathan Long

Die Verwendung eines ORM anstelle des Lernens von SQL 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 sie optimieren können, wird dies definitiv mehr Schaden als Nutzen verursachen. Ich habe jedoch das Gefühl, dass ich mit einem ORM viel produktiver bin. Ich bevorzuge Rails ActiveRecord, das nicht versucht, so zu tun, als gäbe es keine Datenbank, und nicht im Weg steht, wenn Sie nur SQL schreiben müssen. Ich mache mir allerdings Sorgen, dass einige Leute vertrauen könnten die Redewendungen, die sie zu tief sehen, ohne ein tiefes Verständnis dafür zu haben, was sie tun.

11
Jeremy

Meine Erfahrung: Ich verwende NHibernate mit Linq2NHibernate.

Vorteile:

  • Es wird "Magic Strings" los 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 aufgebaute Code ist einfacher zu ändern
  • Sie können Ihre tatsächliche relationale Datenbank austauschen, ohne zwei separate Repositorys zu verwalten (selten durchgeführt, 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 dem Versprechen entspricht, auf das die meisten Menschen zunächst hoffen. Ich würde niemandem die Schuld geben, dass er ein Anti-Muster 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 behoben.

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 es wahrscheinlich tun, aber ich kann nicht sicher sagen , dass Sie sollten. Ich würde sagen, es ist wie der Unterschied zwischen der Wahl von C++ oder Java/.NET für Ihr Projekt: Benötigen Sie die Flexibilität, die Sie erhalten, wenn Sie auf einer niedrigeren Ebene arbeiten, oder möchten Sie lieber auf einer höheren Ebene arbeiten und (angeblich) mehr sein? produktiv? Die normale Antwort ist, auf einem so hohen Niveau zu arbeiten, wie Sie mit davonkommen können. Das bedeutet normalerweise die Verwendung eines ORM.

11
Scott Whitlock

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 Ebene der Anwendung, in der die Sprache des Unternehmens genau mit der Sprache des Entwicklungsteams übereinstimmt. Das ORM ist ein Wegbereiter dafür, wenn das ORM sinnvoll eingesetzt wird.

Die Schwäche ist, dass die Anzahl der Leute, die wirklich, wirklich objektorientierte Programmierung erhalten, ziemlich gering ist. Viele Leute schreiben Spaghetti und Fleischbällchen mit stark gekoppelten Objekten, die wenig eigenes Verhalten haben, und das tatsächliche Verhalten endet in abscheulichen 8000-Zeilen-Klassen "Service" und "Manager", und dieser Code ist oft so verworren, dass jeder Angst hat es zu ändern, weil sie nicht herausfinden können, was die Nebenwirkungen sein werden.

Außerdem verstehen viele Menschen das relationale Modell nicht wirklich. Ein ORM wird ihnen nicht helfen, es zu bekommen, und es wird ihnen nicht helfen, indem sie das relationale Modell abstrahieren. Sie können sich nur frühzeitig auf Ihre Domain-Ebene konzentrieren und dies richtig machen, bevor Sie sich zu viele Gedanken über das Datenbankdesign machen. Bei guter Anwendung können Sie mithilfe sinnvoller Schemamigrationstools und ORM verhindern, dass sich Code-Schulden aufbauen.

Ich habe Anwendungen erstellt, in denen ein ORM den Anwendungscode einfach, lesbar und testbar hielt und eine angemessene Leistung hatte. 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 das ORM selbst wenig damit zu tun hatte, außer dass das ältere Engineering-Team keinen schlechten Code schrieb, der die Anwendungsdomäne schlecht modellierte, sondern schlechten Code, der die Anwendungsdomäne schlecht modellierte, UND schlechten Service-Layer-Code, der alles vernachlässigte der Wert, den ihr ORM ihnen bieten könnte.

ORMs machen Sie nicht schlauer, können aber in den Händen des richtigen Entwicklers zu einem wartbareren und qualitativ hochwertigeren Code führen.

6
JasonTrue

Vielleicht liegt die Antwort in der Umkehrung Ihrer Frage: Ist das Speichern Ihrer Anwendungsdaten in etwas anderem als einer relationalen Datenbank eine gute Idee? Welche Probleme beseitigen Sie und welche anderen Probleme werden Sie aufgreifen? Können Sie ohne die Möglichkeit leben, Ihre Daten (Verknüpfungen) einfach zu verweisen oder die gewünschten Datensätze anhand mehrerer Kriterien schnell herauszufiltern? Benötigen Sie keine solide Transaktionsunterstützung (vorausgesetzt, Ihre Alternative verfügt nicht über diese)? Nicht alle Anwendungen benötigen einen stets konsistenten und vollständigen Datenspeicher.

Ich denke, das eigentliche Anti-Pattern hier könnte darin bestehen, eine relationale Datenbank zu verwenden, wenn Sie keine benötigen. Wenn Sie eines brauchen, dann brauchen Sie ORM, und es ist definitiv kein Anti-Pattern.

5
TMN

ORM ist ein Werkzeug. Wie alle Werkzeuge funktionieren sie bei sachgemäßer Verwendung recht gut. Bei unsachgemäßer Verwendung benötigt es einen größeren Hammer und etwas Klebeband.

Im Fall des aktuellen Projekts, an dem ich arbeite, wird es von Nicht-Entwicklern (Maschinenbauingenieure, 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 schafft die betroffene Agentur nicht ab), daher sind die zukünftigen Wartungskapazitäten ein wichtiger Faktor für unsere Überlegungen.

4
Tangurena