Ist ORM immer noch das "Vietnam der Informatik"?

Question

Ich lese diese Stelle und ich habe festgestellt, dass sie aus dem Jahr 2006 stammt. Ich könnte so oder so auf die ORM, Datenbank Sache gehen, aber ich war nur fragen, ob alles schlechte Jeff sagte über ORM immer noch gilt auch jetzt unter Berücksichtigung der Post ist von 2006.

Answer 1

Es ist immer noch wahr.

Mehr noch als die OO-Software leidet die Datenbank, wenn sie nicht genau so behandelt wird, wie es vorgesehen ist. Und es war nicht beabsichtigt, ihr eine Abstraktionsschicht vorzuschalten.

Ich stelle mir undurchlässige Abstraktionsschichten so vor, als würde man versuchen, eine Lego-Burg zu bauen, bei der alle Teile in einem Kissenbezug eingeschlossen sind. SQL ist verdammt schwer richtig zu machen. Sie hat nicht viele Muster mit der prozeduralen Programmierung gemeinsam, und die besten Praktiken für das eine können für das andere das Gegenteil sein. Man muss in der Lage sein, jedes einzelne Element einer SQL-Anweisung zu verstehen, und eine ziemlich gute Vorstellung davon haben, was sie tun soll und was sie tatsächlich tut.

Viele Menschen scheinen zu glauben, dass es wie beim Hufeisenwerfen reicht, wenn man nah dran ist - wenn die richtige Antwort herausspringt, bedeutet das, dass man fast am Ziel ist. In SQL ist das einfach nicht wahr.

RoR und das ActiveRecord-Pattern haben sich aus diesem Grund zu Recht den Ruf von Ressourcenfressern in Datenbanken erworben. Ein optimiertes ActiveRecord-Design ist in den meisten Fällen ein suboptimales SQL-Design, da es die Zerlegung von SQL-Anweisungen fördert.

Answer 2

Ja.

Objektorientiert ist immer noch objektorientiert und Relational ist immer noch Mengenorientiert . In den letzten zwei Jahren hat sich an diesen beiden Paradigmen nichts geändert, so dass sie besser zusammenarbeiten.

In den Augen vieler Menschen ist SQL hässlich, komplex und verwirrend. Aber der Versuch, eine objektorientierte Schnittstelle für dieselbe Funktionalität zu schaffen, ist immer hässlicher, komplexer und hat eine steilere Lernkurve.

Bei jeder Programmierung gibt es einen Kompromiss zwischen Flexibilität y Annahmen . Frameworks (wie Rails) versuchen das Problem zu lösen, indem sie "meinungsabhängig" sind. Das heißt, sie schränken die Flexibilität entweder der relationalen oder der objektorientierten Aspekte des Problems ein, indem sie Annahmen darüber treffen, wie die Daten strukturiert sind und welche Operationen man mit ihnen durchführen kann. Natürlich wird durch die Vereinfachung des Problemraums auch die Lösung einfacher.

Außerdem ist es frustrierend, wenn man feststellt, dass ein ORM-Framework unvollständig ist, so dass einige gewöhnliche SQL-Operationen in einem bestimmten ORM keine Lösung haben. Dies ist auch eine Folge von "meinungsbetonten" Frameworks.

Answer 3

Viele Web 2.0-Unternehmen arbeiten an Key-Value-Stores. Und alle diese Unternehmen müssen den gleichen schmerzhaften Prozess durchlaufen, damit es funktioniert.

Wenn ORM das "Vietnam der Informatik" ist, dann ist der Aufbau eines eigenen Key-Value-Stores wahrscheinlich der "Irak der Informatik" :-)

Answer 4

Ich kann nur für meine Erfahrungen sprechen. Ich verwende DAL und DTOs und bin immer noch in der Lage, ziemlich komplexe Abfragen durchzuführen (Joins und so), und ich kann auch auf SPs oder benutzerdefiniertes SQL zurückgreifen, wann immer ich es brauche. Das hat mein Leben einfacher gemacht, meinen Code konsistenter und meine Fristen besser einhaltbar.

Answer 5

Ich denke, von der Annahme auszugehen, dass Jeffs Schlussfolgerungen richtig sind, ist nicht unbedingt gut; ich habe sowohl gespeicherten Prozedurcode als auch JDBC-basierte Datenschichten gewartet und kann sagen, dass diese jede Menge Wartungsprobleme verursachten, die meist mit der Unfähigkeit zusammenhingen, zu verstehen, was auf einer höheren Ebene vor sich ging.

Eine Datenbank ist notwendigerweise niedrigschwellig; sie speichert im Wesentlichen Zahlen und Zeichenketten. Geschäftslogik ist High-Level. Aus diesem Grund gibt es die Abstraktion.

Ich persönlich denke, dass der Weg über Rails/ActiveRecord die beste Lösung ist, um ein Objekt-/Domänenmodell zu haben, aber auch in der Lage zu sein, die Vorteile einer relationalen Datenbank zu nutzen.

Also: ORM nicht wegwerfen, aber auch nicht standardmäßig einsetzen. Es ist ein Werkzeug, das bestimmte Probleme löst. Es zu ignorieren, wäre ignorant, und es immer zu verwenden, wäre arrogant.