Welche Art von Webentwicklungsprojekten profitieren von ORM?

10

Zunächst möchte ich sagen, dass ich 95% meiner Datenbankarbeit mit SQL erledigt habe. Kürzlich habe ich verschiedene ORMs wie NHibernate und Doctrine untersucht.

Ich sehe die Vorteile, nicht viel SQL zu kennen und die Datenbankportabilität, die ein ORM bietet. Ich kann aber auch sehen, dass die Kenntnis von SQL die Arbeit mit einem ORM effektiver macht, und ich kann mir nur einmal in meiner Karriere vorstellen, dass die größte Änderung einer Anwendung der Datenbankanbieter wäre.

Da ich mit dem Schreiben von SQL sehr vertraut bin und anscheinend die oft gelehrten Vorteile der Verwendung eines ORM nicht realisiere, lautet meine Frage an schwere ORM-Benutzer:

Welche Art von Webentwicklungsprojekten profitieren am meisten von der Verwendung von ORM?

Fred Wilson
quelle
3
Die Antwort lautet "Alle von ihnen". Aber das wollen Sie wahrscheinlich nicht wissen. Möglicherweise möchten Sie Ihre Frage verfeinern, um spezifischere Informationen zu erhalten.
S.Lott
1
Für mich ist SQL derzeit einfacher zu produzieren, aber das liegt nur an meiner Eingewöhnung (oder Unwissenheit). Ich habe gelesen, dass ORM nicht immer die beste Wahl ist, da es langsamer als normales SQL ist. Viele Entwickler haben jedoch angegeben, dass dies normalerweise nicht wichtig ist. Ich bin hauptsächlich neugierig auf Projekte, die am besten für ORM geeignet sind. Ich kann sehen, dass die meisten Antworten wahrscheinlich "alle" sein werden, und das ist auch in Ordnung. Ich suche keine konkrete Antwort. :)
Fred Wilson
Wenn Sie nicht nach weiteren Details fragen, werden Sie nicht viel lernen.
S.Lott

Antworten:

5

(Fast) alle Anwendungen profitieren von ORM.

Erstens stimme ich den Vorteilen, die Sie für ORM auflisten, nicht zu .

  • Die Verwendung von ORM bedeutet nicht unbedingt, dass Sie SQL nicht kennen müssen. Kenntnisse in SQL helfen zu verstehen, was das ORM-Tool tatsächlich tut, was besonders beim Debuggen hilfreich ist. Darüber hinaus kann SQL tatsächlich erforderlich sein, um komplexe Abfragen zu entwickeln, die über die Fähigkeiten Ihres gewählten ORM hinausgehen.
  • Und wie Sie sagen, ist Portabilität im wirklichen Leben selten ein Problem.

Stattdessen sind die wirklichen Vorteile von ORM:

  • ORM spart Programmiererzeit, da es das Schreiben von Tonnen von CRUD-Logik in SQL spart
  • Viele ORMs enthalten komplexe Caching-Logik usw., die schwer zu schreiben und zu debuggen ist. Dies spart nicht nur Zeit, sondern auch die Zuverlässigkeit und Wartbarkeit Ihrer Anwendung (oder spart Ihnen zumindest die Zeit, die Sie benötigen, um dieselben Ergebnisse zu erzielen).
  • Die besten ORMs haben eine Community von Benutzern , die das Produkt aktiv entwickeln, warten und unterstützen. Die Community rund um benutzerdefiniertes SQL konzentriert sich bestenfalls etwas weniger auf die Probleme, die wir lösen müssen.

Wie Sie kommentieren, ist ein Nachteil von ORM ein Leistungsverlust. Dies kann jedoch normalerweise durch Ausgaben für mehr Hardware ausgeglichen werden.

In der Regel ist die Programmierzeit teurer als die Hardware, daher ist ORM im Allgemeinen eine gute Option, anstatt SQL von Hand zu codieren.

ORM eignet sich am besten für Anwendungen mit einer ziemlich einfachen CRUD-Datenbanklogik. ORM ist weniger effektiv für :

  • Anwendungen, die wenig oder keinen Datenbankzugriff benötigen.
  • Anwendungen, die weitgehend von komplexen Abfragen und sehr wenig einfacher CRUD-Logik abhängig sind
  • Situationen, in denen die Leistung kritisch ist, in denen jedoch keine Möglichkeit besteht, schnellere Hardware bereitzustellen

Nach meiner Erfahrung sind diese Situationen selten. Daher meine Antwort.

Kramii
quelle
"Die Verwendung von ORM bedeutet nicht unbedingt, dass Sie SQL nicht kennen müssen." - So wahr. Einer der Vorteile, die ich in einer Teamumgebung sehe, besteht darin, dass wir das SQL-Skillset so konzentrieren können, dass nicht jeder Entwickler, der auf der Business-Ebene arbeitet, ein Experte sein muss.
Fred Wilson
1
Bei komplexen Abfragen können Sie jederzeit zu SQL zurückkehren und eine SQL-Abfrage schreiben.
Harsimranb
4

Ich schreibe auch gerne SQL. Ich fühle mich auch viel wohler, wenn ich überhaupt kein SQL schreiben muss und mir keine Sorgen über das Verbinden, Trennen, Pooling usw. mit einer Datenbank mache.

Also ... ich werde das Negative Ihrer Frage beantworten. Die einzigen Webentwicklungsprojekte, die NICHT von einem ORM profitieren, sind diejenigen, die überhaupt nicht mit einer Datenbank sprechen. Was ich glaube, ist die Minderheit (falls vorhanden).

Otávio Décio
quelle
+1: Ich halte mich auch für sehr kompetent in SQL, bevorzuge aber immer noch einen OR / M. Tatsächlich würde ich sagen, dass Sie SQL definitiv im Griff haben müssen, um ein OR / M gut nutzen zu können. Andernfalls werden Sie das Problem nie finden, wenn die Abstraktion leckt. "nicht viel SQL wissen müssen" ist keine Funktion. Für mich dreht sich alles um Produktivitätssteigerungen und darum, dass der Compiler die Probleme findet, nicht die Laufzeit und die OR / Ms (insbesondere neuere Generika / Linq-basierte sind großartig).
Brook
@Brook - Ich stimme voll und ganz zu. Die Verwendung eines OR / M bedeutet nicht, dass SQL-Kenntnisse optional sind.
Otávio Décio
2

Aufgrund meiner Erfahrung mit ASP.NET WebForms würde ich vorschlagen, dass Webprojekte, die Stateful Web Frameworks verwenden, am meisten von der Verwendung eines ORM profitieren.

Mit einem Stateful Framework wird das Markup automatisch hinter den Kulissen generiert, basierend auf der Hierarchie der aktiven Serversteuerelemente. Es ist verlockend, diese Steuerelemente zu laden und ihren Status automatisch in der Datenbank beizubehalten. Hier hilft ORM.

Sie abstrahieren das Ende der Pipeline (HTML-Ausgabe) und es ist natürlich einladend, mit dem Anfang (Datenquelle) auf die gleiche Weise umzugehen, sodass Sie nur im Anwendungscode innerhalb Ihrer Geschäftslogik bleiben.

Nicht, dass ich nicht sage, dass dies eine gute Möglichkeit ist, Dinge zu tun. Hier passt ORM natürlich.


quelle
2

In Anwendungen, in denen Sie ein großes, sehr verbundenes Objektmodell haben, erspart Ihnen ein ORM, immer wieder dieselben Verknüpfungen zu schreiben.

Ein weiterer Vorteil ist das verzögerte Laden, bei dem eine API ein Objektdiagramm zurückgeben soll, bei dem der Client der API nur eine Teilmenge dieses Diagramms verwendet.

Paul Sanwald
quelle
1

Ich glaube, Sie verwechseln ein ORM mit einem DBAL .

Das Konzept, auf das Sie sich beziehen, ist ein Database Abstraction Layer (DBAL), mit dem Sie portables "SQL" schreiben können, das nicht vom zugrunde liegenden Datenbanksystem abhängig ist.

Ein ORM hingegen (der (fast?) Immer auf einer DBAL aufgebaut ist):

Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. (Wikipedia)

Mit einem ORM können Sie einfach Daten aus einer flachen Datenbank in eine aufgeblasene Objektdarstellung konvertieren.

Craige
quelle
Danke für die Klarstellung. Der Hauptgrund für mich, zu ORM zu wechseln, besteht darin, mich mehr auf OOP zu konzentrieren und nicht mehr so ​​viel SQL zu schreiben, wenn dies für einige Projekte sinnvoll ist.
Fred Wilson
1

Projekte, die von ORM nicht profitieren würden, wären:

  • diejenigen, die nicht objektorientiert sind;
  • diejenigen, die keine Daten speichern müssen;
  • diejenigen, die eine objektorientierte Datenbank verwenden, benötigen daher keine zusätzliche Zuordnungsschicht.
  • diejenigen, die keine relationale NoSQL-Lösung verwenden;
vartec
quelle