Ist ORM immer noch ein Anti-Pattern?

• ORM (Object-Relational Mapper) wird in der Softwareentwicklung oft als Anti-Pattern kritisiert.
• Diese Kritik ist jedoch übertrieben, und ORMs sind wie andere Software-Tools nicht von Natur aus schlecht.
• Das eigentliche Problem bei ORMs ist oft, dass sie falsch eingesetzt oder missverstanden werden.
• Da ORM und relationale Datenbanken in unterschiedlichen Paradigmen arbeiten, können bei Datenmodellierung und Beziehungen anspruchsvolle Probleme entstehen.
• ORM verletzt die Prinzipien der Single Responsibility Principle (SRP) und der Separation of Concerns (SOC), aber diese Kritikpunkte sind keineswegs endgültig ausschlaggebend.
• Die tatsächlichen Probleme von ORM liegen in Effizienz und Sichtbarkeit.
• Wenn ORM nicht korrekt verwendet wird, kann es ineffizient sein, verfügt jedoch auch über Funktionen, mit denen sich Queries optimieren und die Performance verbessern lassen.
• Das N+1-Problem, bei dem ORM mehrfach zwischen Anwendung und Datenbank hin- und herkommuniziert, lässt sich durch den Einsatz eines Data Loaders abmildern.
• Das größte Problem von ORM ist Sichtbarkeit und Debugging. Es liefert möglicherweise keine klaren Fehlermeldungen oder erschwert das Verständnis und die Behebung von Problemen.
• Bei richtiger Verwendung kann ORM genauso effizient sein wie rohes SQL, aber Entwickler müssen dafür die Funktionen und nativen SQL-Entsprechungen nutzen.
• Bei einigen komplexen oder problematischen Queries kann es notwendig sein, auf rohe SQL-Queries umzusteigen.
• Insgesamt ist ORM nicht von Natur aus schlecht, erfordert aber einen sorgfältigen und sachkundigen Einsatz, um potenzielle Probleme zu vermeiden.

[GN⁺]

Hacker-News-Meinungen

• Die Grenzen und Nachteile von ORMs werden kritisiert, etwa dass sich damit keine anderen Datenbanken verwenden lassen und dennoch SQL-Kenntnisse erforderlich sind.
• Es gilt als besserer Ansatz, die Datenebene mit String-Interpolation und in einer Weise, die rohem JDBC nahekommt, Abfrage für Abfrage aufzubauen.
• ORMs sind oft nur auf grundlegendes Mapping von Tabellen und Views beschränkt und ignorieren fortgeschrittene Funktionen und Möglichkeiten von SQL.
• Es gibt zwei Arten von ORMs: solche, die auf einem Domain-Modell basieren, und solche, die aus einer bestehenden Datenbank ein Domain-Modell erzeugen.
• ORMs mit verschiedenen Implementierungen und Funktionsumfängen wie jOOQ und Hibernate werden jeweils für unterschiedliche Zwecke eingesetzt.
• ORMs können in komplexen Anwendungen mit vielen Tabellen und geeigneten Fremdschlüsselbeziehungen nützlich sein.
• Die Verwendung von rohem SQL in String-Literalen gilt als Alternative zu ORMs; außerdem kann man Werkzeuge einsetzen, die Query-Wrapper erzeugen.
• Bevorzugt werden pragmatische ORMs, die nicht versuchen, alles in einem Bundle zu verstecken oder eine eigene Query-Sprache einzuführen.
• SQLAlchemy wird für einen Ansatz gelobt, der SQL nicht neu erfindet, sondern eine bequeme Query-Schicht bereitstellt.
• Ohne ORM müssen Entwickler ihre eigene Datenbankschnittstelle schreiben und pflegen, was zu Bugs und Sicherheitslücken führen kann.
• Die Kritik, dass ORMs gegen die SOLID-Prinzipien verstoßen, wird als Konflikt zwischen akademischer Lehre und realer Entwicklung gesehen.
• Unerfahrenheit oder der Einfluss akademischer Praktiken können zu Problemen und Budgetüberschreitungen führen.