webentwicklung-frage-antwort-db.com.de

Gibt es gute Gründe, kein ORM zu verwenden?

Während meiner Ausbildung habe ich NHibernate für einige kleinere Projekte verwendet, die ich größtenteils selbst programmiert und entworfen habe. Bevor Sie ein größeres Projekt starten, wurde diskutiert, wie Sie den Datenzugriff gestalten und ob Sie eine ORM-Ebene verwenden sollen oder nicht. Da ich noch in meiner Ausbildung bin und mich immer noch als Anfänger in der Unternehmensprogrammierung betrachte, habe ich meiner Meinung nach nicht wirklich versucht, Push durchzuführen. Das heißt, die Verwendung eines objektrelationalen Mappers für die Datenbank kann die Entwicklung erheblich vereinfachen. Die anderen Programmierer im Entwicklerteam sind viel erfahrener als ich, daher denke ich, dass ich einfach das tun werde, was sie sagen. :-)

Ich verstehe jedoch zwei der Hauptgründe für die Nichtverwendung von NHibernate oder eines ähnlichen Projekts nicht vollständig:

  1. Sie können einfach eigene Datenzugriffsobjekte mit SQL-Abfragen erstellen und diese Abfragen aus Microsoft SQL Server Management Studio kopieren.
  2. Das Debuggen eines ORM kann schwierig sein.

Natürlich könnte ich meine Datenzugriffsschicht auch nur mit einer Menge von SELECTs usw. aufbauen, aber hier vermisse ich den Vorteil automatischer Verknüpfungen, des verzögerten Ladens von Proxy-Klassen und eines geringeren Wartungsaufwands, wenn eine Tabelle eine neue erhält Spalte oder eine Spalte wird umbenannt. (Aktualisieren zahlreicher SELECT-, INSERT- und UPDATE -Anfragen im Vergleich zum Aktualisieren der Mapping-Konfiguration und möglicherweise zum Umgestalten der Geschäftsklassen und DTOs.)

Mit NHibernate können Sie auch auf unvorhergesehene Probleme stoßen, wenn Sie das Framework nicht genau kennen. Dies könnte beispielsweise darin bestehen, der Datei "Table.hbm.xml" zu vertrauen, in der Sie die Länge einer Zeichenfolge festlegen, die automatisch überprüft werden soll. Ich kann mir jedoch auch ähnliche Fehler in einer "einfachen" abfragebasierten SqlConnection-Datenzugriffsebene vorstellen.

Sind diese oben genannten Argumente wirklich ein guter Grund, kein ORM für eine nicht triviale datenbankbasierte Unternehmensanwendung zu verwenden? Gibt es wahrscheinlich andere Argumente, die sie/ich möglicherweise übersehen haben?

(Ich sollte wahrscheinlich hinzufügen, dass dies meiner Meinung nach die erste "große" .NET/C # -basierte Anwendung ist, für die Teamarbeit erforderlich ist. Bewährte Methoden, die beim Stapelüberlauf als ziemlich normal angesehen werden, wie Unit-Tests oder kontinuierliche Integration, sind keine -bis jetzt hier.)

101
hangy

ORMs haben in den letzten Jahren ein rasantes Wachstum verzeichnet, und Ihre erfahreneren Mitarbeiter denken möglicherweise immer noch in der Mentalität "Jeder Datenbankaufruf sollte über eine gespeicherte Prozedur erfolgen".

Warum würde ein ORM das Debuggen erschweren? Sie erhalten das gleiche Ergebnis, unabhängig davon, ob es aus einem gespeicherten Prozess oder aus dem ORM stammt.

Der einzige wirkliche Nachteil, den ich mir bei einem ORM vorstellen kann, ist, dass das Sicherheitsmodell etwas weniger flexibel ist.

BEARBEITEN: Ich habe Ihre Frage gerade noch einmal gelesen und es sieht so aus, als würden sie die Abfragen kopieren und in Inline-SQL einfügen. Dadurch gleicht das Sicherheitsmodell einem ORM, sodass dieser Ansatz gegenüber einem ORM absolut keinen Vorteil hätte. Wenn sie nicht parametrisierte Abfragen verwenden, ist dies tatsächlich ein Sicherheitsrisiko.

28
Giovanni Galbo

Die kurze Antwort lautet ja, es gibt wirklich gute Gründe. In der Tat gibt es Fälle, in denen Sie ein ORM einfach nicht verwenden können.

Ich arbeite für ein großes Finanzinstitut, und wir müssen viele Sicherheitsrichtlinien einhalten. Um die uns auferlegten Regeln und Vorschriften einzuhalten, besteht die einzige Möglichkeit, Audits zu bestehen, darin, den Datenzugriff innerhalb gespeicherter Prozeduren zu halten. Nun mögen einige sagen, dass das einfach nur dumm ist, aber ehrlich gesagt ist es das nicht. Die Verwendung eines ORM-Tools bedeutet, dass das Tool/der Entwickler beliebige Elemente einfügen, auswählen, aktualisieren oder löschen kann. Gespeicherte Prozeduren bieten viel mehr Sicherheit, insbesondere in Umgebungen, in denen mit Clientdaten gearbeitet wird. Ich denke, dies ist der Hauptgrund, über den man nachdenken sollte. Sicherheit.

55
Keith Elder

Der Sweet Spot von ORMs

ORMs sind nützlich, um 95% der Abfragen dort zu automatisieren, wo sie anwendbar sind. Ihre besondere Stärke liegt darin, dass Sie eine Anwendung mit einer starken Objektmodellarchitektur und einer Datenbank haben, die gut mit diesem Objektmodell zusammenarbeitet. Wenn Sie einen neuen Build erstellen und über ausgeprägte Modellierungsfähigkeiten in Ihrem Team verfügen, werden Sie mit einem ORM wahrscheinlich gute Ergebnisse erzielen.

Möglicherweise haben Sie eine Handvoll Fragen, die besser von Hand erledigt werden. In diesem Fall haben Sie keine Angst, ein paar gespeicherte Prozeduren zu schreiben, um dies zu handhaben. Selbst wenn Sie beabsichtigen, Ihre App über mehrere DBMS-Plattformen zu portieren, ist der datenbankabhängige Code in der Minderheit. Wenn Sie bedenken, dass Sie Ihre Anwendung auf jeder Plattform testen müssen, auf der Sie sie unterstützen möchten, wird ein wenig zusätzlicher Portierungsaufwand für einige gespeicherte Prozeduren keine großen Auswirkungen auf Ihre Gesamtbetriebskosten haben. In erster Näherung ist 98% portabel genauso gut wie 100% portabel und weitaus besser als gewundene oder schlecht funktionierende Lösungen, um die Grenzen eines ORM zu umgehen.

Ich habe gesehen, dass der frühere Ansatz bei einem sehr großen J2EE-Projekt (100 Mitarbeiterjahre) gut funktioniert.

Wobei ein ORM möglicherweise nicht am besten passt

In anderen Fällen kann es Ansätze geben, die besser zur Anwendung passen als ein ORM. Fowlers Muster der Unternehmensanwendungsarchitektur enthält einen Abschnitt über Datenzugriffsmuster, mit dem sich verschiedene Ansätze für diese Aufgabe recht gut katalogisieren lassen. Einige Beispiele für Situationen, in denen ein ORM möglicherweise nicht anwendbar ist, sind:

  • In einer Anwendung mit einer umfangreichen älteren Codebasis gespeicherter Prozeduren möchten Sie möglicherweise eine funktionsorientierte Datenzugriffsebene (nicht zu verwechseln mit funktionalen Sprachen) verwenden, um die vorhandenen Sprocs zu umschließen. Dadurch werden die vorhandene (und daher getestete und getestete) Datenzugriffsebene und das Datenbankdesign wiederverwendet, was häufig einen erheblichen Entwicklungs- und Testaufwand darstellt und die Migration von Daten in ein neues Datenbankmodell erspart. Es ist oft eine gute Möglichkeit, Java Layer um ältere PL/SQL-Codebasen zu wickeln oder Rich-Client-VB-, Powerbuilder- oder Delphi-Apps mit Webschnittstellen neu auszurichten.

  • In einer Variante erben Sie ein Datenmodell, das nicht unbedingt für die O-R-Zuordnung geeignet ist. Wenn Sie (zum Beispiel) eine Schnittstelle schreiben, die Daten von einer fremden Schnittstelle auffüllt oder extrahiert, ist es möglicherweise besser, direkt mit der Datenbank zu arbeiten.

  • Finanzanwendungen oder andere Arten von Systemen, bei denen die systemübergreifende Datenintegrität wichtig ist, insbesondere wenn Sie komplexe verteilte Transaktionen mit zweiphasigem Commit verwenden. Möglicherweise müssen Sie Ihre Transaktionen besser verwalten, als dies mit einem ORM möglich ist.

  • Leistungsstarke Anwendungen, bei denen Sie den Datenbankzugriff wirklich optimieren möchten. In diesem Fall kann es vorzuziehen sein, auf einer niedrigeren Ebene zu arbeiten.

  • Situationen, in denen Sie einen etablierten Datenzugriffsmechanismus wie ADO.Net verwenden, der "gut genug" ist und mit der Plattform gut spielt, sind von größerem Nutzen als der ORM.

  • Manchmal sind Daten nur Daten - es kann beispielsweise sein, dass Ihre Anwendung mit "Transaktionen" und nicht mit "Objekten" arbeitet und dies eine vernünftige Sicht auf die Domäne ist. Ein Beispiel hierfür könnte ein Finanzpaket sein, in dem Sie Transaktionen mit konfigurierbaren Analysefeldern haben. Während die Anwendung selbst auf einer OO-Plattform erstellt werden kann, ist sie nicht an ein einzelnes Geschäftsdomänenmodell gebunden und kennt möglicherweise nicht viel mehr als GL Codes, Konten, Dokumenttypen und ein halbes Dutzend Analysefelder: In diesem Fall ist der Anwendung ein Geschäftsdomänenmodell als solches nicht bekannt, und ein Objektmodell (über die Hauptbuchstruktur hinaus) ist für die Anwendung nicht relevant.

Die Verwendung eines ORM als Erstes vereinfacht weder das Testen Ihres Codes, noch bietet sie notwendigerweise Vorteile in einem Continuous Integration-Szenario.

Meiner Erfahrung nach kann die Verwendung eines ORM die Entwicklungsgeschwindigkeit erhöhen. Die wichtigsten Probleme, die Sie lösen müssen, sind:

  1. Testen Sie Ihren Code
  2. Pflegen Sie Ihren Code

Die Lösungen hierfür sind:

  1. Mach deinen Code testbar (mit SOLID Prinzipien)
  2. Schreiben Sie automatisierte Tests für so viel Code wie möglich
  3. Führen Sie die automatisierten Tests so oft wie möglich aus

Bei Ihrer Frage scheinen die beiden Einwände, die Sie auflisten, eher Unwissenheit als irgendetwas anderes zu sein.

Wenn SELECT-Abfragen nicht von Hand geschrieben werden können (was vermutlich der Grund ist, warum das Kopieren und Einfügen erforderlich ist), scheint dies darauf hinzudeuten, dass dringend SQL-Schulungen erforderlich sind.

Es gibt zwei Gründe, warum ich kein ORM verwenden würde:

  1. Es ist strengstens verboten durch die Firmenpolitik (in diesem Fall würde ich woanders arbeiten gehen)
  2. Das Projekt ist extrem datenintensiv und die Verwendung von herstellerspezifischen Lösungen (wie BulkInsert) ist sinnvoller.

Die üblichen Abneigungen gegen ORMs (insbesondere NHibernate) sind:

  1. Geschwindigkeit

    Es gibt keinen Grund, warum die Verwendung eines ORM langsamer ist als der handcodierte Datenzugriff. Aufgrund der integrierten Zwischenspeicherung und Optimierungen kann dies sogar schneller gehen. Ein guter ORM erzeugt einen wiederholbaren Satz von Abfragen, für die Sie Ihr Schema optimieren können. Ein guter ORM ermöglicht auch das effiziente Abrufen zugehöriger Daten unter Verwendung verschiedener Abrufstrategien.

  2. Komplexität

    In Bezug auf die Komplexität bedeutet die Verwendung eines ORM weniger Code, was im Allgemeinen weniger Komplexität bedeutet. Viele Menschen, die handgeschriebenen (oder durch Code generierten) Datenzugriff verwenden, finden sich dabei, ihr eigenes Framework über "Low-Level" -Datenzugriffsbibliotheken zu schreiben (wie das Schreiben von Hilfsmethoden für ADO.Net). Diese sind komplexer und, was noch schlimmer ist, selten gut dokumentiert oder getestet.
    Wenn Sie sich speziell mit NHibernate beschäftigen, können Tools wie Fluent NHibernate und Linq To NHibernate die Lernkurve ebenfalls abschwächen.

Das, was mich an der gesamten ORM-Debatte bewegt, ist, dass dieselben Leute, die behaupten, dass die Verwendung eines ORM zu schwierig/langsam ist/was auch immer, dieselben Leute sind, die mit Linq To SQL oder typisierten Datensätzen mehr als zufrieden sind. Während das Linq To Sql ein großer Schritt in die richtige Richtung ist, ist es noch einige Lichtjahre dahinter, wo sich einige der Open-Source-ORMs befinden. Die Frameworks für Typed Datasets und für Linq To Sql sind jedoch immer noch sehr komplex, und es ist dumm, sie zu verwenden, um die (Table = Class) + (Basic CRUD) zu überschreiten.

Mein Rat ist, dass Sie, wenn Sie am Ende des Tages kein ORM erhalten können, sicherstellen, dass Ihr Datenzugriff vom Rest des Codes getrennt ist und dass Sie den Rat der Gang Of Four befolgen, zu codieren eine Schnittstelle. Besorgen Sie sich auch ein Abhängigkeitsinjektions-Framework, um die Verkabelung durchzuführen.

(Wie ist das für einen Scherz?)

37
David Kemp

Es gibt eine Vielzahl gängiger Probleme, für die ORM-Tools wie Hibernate von Gott gesandt werden, und einige, für die dies ein Hindernis darstellt. Ich weiß nicht genug über Ihr Projekt, um zu wissen, um welches es sich handelt.

Eine der Stärken von Hibernate ist, dass Sie Dinge nur dreimal sagen müssen: Jede Eigenschaft wird in der Klasse, in der .hbm.xml-Datei und in der Datenbank erwähnt. Bei SQL-Abfragen befinden sich Ihre Eigenschaften in der Klasse, der Datenbank, den select-Anweisungen, den insert-Anweisungen, den update-Anweisungen, den delete-Anweisungen und dem gesamten Marshalling- und Unmarshalling-Code, der Ihre SQL-Abfragen unterstützt! Dies kann schnell chaotisch werden. Andererseits wissen Sie, wie es funktioniert. Sie können es debuggen. Es ist alles in deiner eigenen Ausdauer-Ebene, nicht in den Eingeweiden eines Drittanbieter-Tools vergraben.

Hibernate könnte ein Aushängeschild für Spolskys Gesetz der undichten Abstraktionen sein. Holen Sie sich ein wenig aus dem Schuss, und Sie müssen tiefe interne Funktionsweisen des Werkzeugs kennen. Es kann sehr ärgerlich sein, wenn Sie wissen, dass Sie die SQL in Minuten behoben haben könnten, aber stattdessen verbringen Sie Stunden damit, Ihr Dang-Tool dazu zu bringen, vernünftige SQL zu generieren. Debuggen ist manchmal ein Albtraum, aber es ist schwer, Leute zu überzeugen, die noch nicht dort waren.

BEARBEITEN: Möglicherweise möchten Sie in iBatis.NET nachsehen, wenn Sie sich nicht mit NHibernate befassen und die Kontrolle über Ihre SQL-Abfragen haben möchten.

EDIT 2: Hier ist die große rote Fahne: "Gute Praktiken, die bei Stack Overflow als normal angesehen werden, wie Unit-Tests oder kontinuierliche Integration, gibt es hier bisher nicht." Also, diese "erfahrenen" Entwickler, was haben sie in der Entwicklung erlebt? Ihre Arbeitsplatzsicherheit? Es hört sich so an, als gehörten Sie zu den Leuten, die sich nicht besonders für dieses Gebiet interessieren. Lassen Sie sich also nicht von ihnen töten. Sie müssen das Gleichgewicht sein. Schlage einen Kampf vor.

32
Alan Hensel

Ich habe an einem Projekt gearbeitet, bei dem es sehr erfolgreich war, kein ORM zu verwenden. Es war ein Projekt, das

  1. Musste von Anfang an horizontal skalierbar sein
  2. Musste schnell entwickelt werden
  3. Hatte ein relativ einfaches Domainmodell

Die Zeit, die nötig gewesen wäre, um NHibernate in einer horizontal partitionierten Struktur zum Laufen zu bringen, wäre viel länger gewesen als die Zeit, die für die Entwicklung eines supereinfachen Datamappers erforderlich gewesen wäre, der unser Partitionsschema kannte ...

In 90% der Projekte, in denen ich an einem ORM gearbeitet habe, war dies eine unschätzbare Hilfe. Aber es gibt einige sehr spezielle Umstände, unter denen ich sehe, dass ein ORM nicht das Beste ist.

12
Mike

Lassen Sie mich zunächst sagen, dass ORMs Ihr Entwicklungsleben erleichtern können, wenn sie ordnungsgemäß integriert werden. Es gibt jedoch einige Probleme, bei denen das ORM Sie tatsächlich daran hindern kann, Ihre festgelegten Anforderungen und Ziele zu erreichen.

Ich habe festgestellt, dass ich beim Entwerfen von Systemen mit hohen Leistungsanforderungen häufig gezwungen bin, Wege zu finden, um das System leistungsfähiger zu machen. Oftmals habe ich eine Lösung mit einem hohen Schreibleistungsprofil (dh, wir schreiben viel mehr Daten als wir lesen). In diesen Fällen möchte ich die Möglichkeiten der Datenbankplattform nutzen, um unsere Leistungsziele zu erreichen (OLTP, nicht OLAP). Wenn ich SQL Server verwende und weiß, dass ich eine Menge Daten zu schreiben habe, warum sollte ich dann keine Masseneinfügung verwenden? Nun, wie Sie vielleicht bereits herausgefunden haben, die meisten ORMS (ich weiß nicht, ob Selbst ein einzelner hat nicht die Möglichkeit, plattformspezifische Vorteile wie Masseneinsatz zu nutzen.

Sie sollten wissen, dass Sie die ORM- und Nicht-ORM-Techniken mischen können. Ich habe gerade festgestellt, dass es eine Handvoll Edge-Fälle gibt, in denen ORMs Ihre Anforderungen nicht unterstützen können und Sie sie für diese Fälle umgehen müssen.

11
Ajaxx

Für eine nicht triviale datenbankbasierte Unternehmensanwendung gibt es wirklich keine Rechtfertigung dafür, kein ORM zu verwenden.

Merkmale beiseite:

  • Wenn Sie kein ORM verwenden, lösen Sie ein Problem, das bereits wiederholt von großen Communities oder Unternehmen mit erheblichen Ressourcen gelöst wurde.
  • Durch die Verwendung eines ORM profitiert das Kernstück Ihrer Datenzugriffsschicht von den Debug-Bemühungen dieser Community oder Firma.

Berücksichtigen Sie die Vorteile der Verwendung von ADO.NET im Vergleich zum Schreiben des Codes zum Parsen des tabellarischen Datenstroms.

Ich habe gesehen, dass Unkenntnis in der Verwendung eines ORM die Verachtung eines Entwicklers für ORMs rechtfertigt. Zum Beispiel: Eifriges Laden (etwas, von dem ich bemerkt habe, dass Sie es nicht erwähnt haben). Stellen Sie sich vor, Sie möchten einen Kunden und alle seine Bestellungen sowie alle Bestelldetails abrufen. Wenn Sie sich nur auf das langsame Laden verlassen, werden Sie Ihre ORM-Erfahrung mit der Meinung verlassen: "ORMs sind langsam." Wenn Sie lernen, wie man eifriges Laden einsetzt, erledigen Sie in 2 Minuten mit 5 Codezeilen, was Ihre Kollegen in einem halben Tag implementieren müssen: eine Abfrage an die Datenbank und das Binden der Ergebnisse an eine Hierarchie von Objekten. Ein weiteres Beispiel wäre der Schmerz, manuell SQL-Abfragen zu schreiben, um Paging zu implementieren.

Die mögliche Ausnahme zur Verwendung eines ORM wäre, wenn diese Anwendung ein ORM-Framework wäre, das zur Anwendung spezialisierter Geschäftslogikabstraktionen und zur Wiederverwendung in mehreren Projekten entwickelt wurde. Selbst wenn dies der Fall wäre, würden Sie eine schnellere Übernahme erzielen, indem Sie ein vorhandenes ORM mit diesen Abstraktionen erweitern.

Lassen Sie sich von den Erfahrungen Ihrer Senior-Teammitglieder nicht in die entgegengesetzte Richtung der Entwicklung der Informatik ziehen. Ich entwickle mich seit 23 Jahren professionell und eine der Konstanten ist die Verachtung des Neuen durch die alte Schule. ORMs beziehen sich auf SQL, wie es die C-Sprache für Assembly war, und Sie können wetten, dass die Entsprechungen zu C++ und C # auf dem Weg sind. Eine Zeile New-School-Code entspricht 20 Zeilen Old-School.

11
DaveMorganTexas

Wenn Sie 50000000 Datensätze aktualisieren müssen. Setze eine Flagge oder was auch immer.

Versuchen Sie dies mit einem ORM ohne Aufrufen einer gespeicherten Prozedur oder nativen SQL-Befehlen.

Update 1: Versuchen Sie auch, einen Datensatz mit nur wenigen Feldern abzurufen. (Wenn Sie einen sehr "breiten" Tisch haben). Oder ein skalares Ergebnis. ORMs saugen auch daran.

PDATE 2: Es scheint, dass EF 5.0 Beta Batch-Updates verspricht, aber dies ist eine sehr heiße Nachricht (2012, Januar)

9
Andrei Rînea

Ich denke, wenn Sie an größeren Systemen arbeiten, können Sie vielleicht ein Code-Generator-Tool wie CodeSmith anstelle eines ORM verwenden ... Ich habe kürzlich Folgendes gefunden: Cooperator Framework , das gespeicherte SQL Server-Prozeduren generiert und auch Ihre Geschäftsentitäten, Mapper, Gateways, Lazyloads und all das Zeug in C # generiert ... check it out ... es wurde von einem Team hier in Argentinien geschrieben ...

Ich denke, es ist in der Mitte zwischen der Codierung der gesamten Datenzugriffsschicht und der Verwendung eines ORM ...

8
pabloide86

Persönlich habe ich (bis vor kurzem) gegen die Verwendung eines ORM und verwendet, um mit dem Schreiben einer Datenzugriffsschicht auszukommen, die alle SQL-Befehle kapselt. Der Haupteinwand gegen ORMs war, dass ich der ORM-Implementierung nicht vertraute, genau das richtige SQL zu schreiben. Und nach den ORMs zu urteilen, die ich früher gesehen habe (meistens PHP Libraries)), denke ich, dass ich vollkommen recht hatte.

Jetzt wird Django für die meisten meiner Webentwicklungen verwendet, und ich fand das enthaltene ORM sehr praktisch. Da das Datenmodell zuerst in seinen Begriffen und erst später in SQL ausgedrückt wird, funktioniert es perfekt für meine Anforderungen. Ich bin mir sicher, dass es nicht allzu schwer sein wird, daraus herauszuwachsen, und dass man es mit handgeschriebenem SQL ergänzen muss. Aber für CRUD ist der Zugang mehr als genug.

Ich weiß nichts über NHibernate. aber ich denke, es ist auch "gut genug" für das meiste, was Sie brauchen. Aber wenn andere Programmierer dem nicht vertrauen; Es wird ein Hauptverdächtiger bei jedem datenbezogenen Fehler sein, was die Überprüfung langwieriger macht.

Sie könnten versuchen, es schrittweise an Ihrem Arbeitsplatz einzuführen, und sich zunächst auf kleine, offensichtliche Anwendungen wie den einfachen Datenzugriff konzentrieren. Nach einer Weile wird es möglicherweise für Prototypen verwendet und möglicherweise nicht ersetzt ...

6
Javier

Wenn es sich um eine OLAP -Datenbank handelt (z. B. statische, schreibgeschützte Daten, die für Berichte/Analysen verwendet werden usw.), ist die Implementierung eines ORM-Frameworks nicht geeignet. Stattdessen wird die native Datenzugriffsfunktion der Datenbank verwendet B. gespeicherte Prozeduren sind vorzuziehen. ORMs eignen sich besser für OLTP-Systeme.

5
Ray Vega

Ich denke, es gibt viele gute Gründe, kein ORM zu verwenden. In erster Linie bin ich ein .NET-Entwickler und halte mich gerne an das, was mir das wunderbare .NET-Framework bereits zur Verfügung gestellt hat. Es macht alles, was ich möglicherweise brauche. Auf diese Weise bleiben Sie bei einem einheitlicheren Ansatz, und daher ist es viel wahrscheinlicher, dass jeder andere Entwickler, der später am selben Projekt arbeitet, das aufgreift, was sich dort befindet, und mit ihm arbeitet. Die von Microsoft bereits bereitgestellten Datenzugriffsfunktionen sind recht umfangreich. Es gibt keinen Grund, sie zu verwerfen.

Ich bin seit 10 Jahren ein professioneller Entwickler, führe mehrere sehr erfolgreiche Millionen-Dollar-Projekte und habe noch nie eine Anwendung geschrieben, die in der Lage sein musste, auf eine Datenbank umzuschalten. Warum sollten Sie jemals wollen, dass ein Kunde dies tut? Planen Sie sorgfältig, wählen Sie die richtige Datenbank für Ihre Anforderungen aus und bleiben Sie dabei. Persönlich war SQL Server in der Lage, alles zu tun, was ich jemals tun musste. Es ist einfach und es funktioniert großartig. Es gibt sogar eine kostenlose Version, die bis zu 10 GB Daten unterstützt. Oh, und es funktioniert super mit .NET.

Ich musste in letzter Zeit an mehreren Projekten arbeiten, die ein ORM als Datenebene verwenden. Ich denke, es ist schlecht, und ich musste lernen, wie man es ohne jeden Grund benutzt. In den wahnsinnig seltenen Fällen, in denen der Kunde die Datenbanken ändern musste, hätte ich den gesamten Datenlayer problemlos in kürzerer Zeit überarbeiten können, als ich es mit den ORM-Anbietern zu tun gehabt hätte.

Ehrlich gesagt, gibt es eine echte Verwendung für ein ORM: Wenn Sie eine Anwendung wie SAP erstellen, muss diese wirklich auf mehreren Datenbanken ausgeführt werden können. Ansonsten sage ich als Lösungsanbieter meinen Kunden, dass diese Anwendung für die Ausführung auf dieser Datenbank ausgelegt ist und so ist sie. Auch dies war nach 10 Jahren und unzähligen Bewerbungen noch nie ein Problem.

Ansonsten sind ORMs meiner Meinung nach für Entwickler gedacht, die nicht verstehen, dass weniger mehr ist. Je mehr coole Tools von Drittanbietern sie in ihrer App verwenden, desto besser wird ihre App. Ich überlasse solche Dinge den hartnäckigen Freaks, während ich in der Zwischenzeit viel mehr großartige Software herausbringe, mit der jeder Entwickler arbeiten und sofort produktiv sein kann.

4
Danny

Die Erfahrung, die ich mit Hibernate gemacht habe, ist, dass die Semantik subtil ist, und wenn es Probleme gibt, ist es ein bisschen schwer zu verstehen, was unter der Haube falsch läuft. Ich habe von einem Freund gehört, dass man oft mit Kriterien beginnt, dann etwas mehr Flexibilität und HQL benötigt und später bemerkt, dass schließlich Raw-SQL benötigt wird (zum Beispiel, Hibernate hat keine Union AFAIK).

Auch mit ORM neigen die Benutzer leicht dazu, vorhandene Zuordnungen/Modelle zu überbeanspruchen, was dazu führt, dass es ein Objekt mit vielen Attributen gibt, die nicht initialisiert sind. Nach der Abfrage führt Hibernate in der Transaktion einen zusätzlichen Datenabruf durch, was zu einer möglichen Verlangsamung führen kann. Leider gelangt das Modellobjekt im Ruhezustand manchmal in die Ansichtsarchitekturebene, und dann werden LazyInitializationExceptions angezeigt.

Um ORM zu benutzen, sollte man es wirklich verstehen. Leider bekommt man leicht den Eindruck, dass es einfach ist, obwohl es nicht so ist.

3
egaga

Um nicht per se eine Antwort zu sein, möchte ich ein Zitat umformulieren, das ich kürzlich gehört habe. "Ein guter ORM ist wie ein Yeti, jeder redet über einen, aber niemand sieht es."

Wenn ich ein ORM in die Hand nehme, habe ich normalerweise mit den Problemen/Einschränkungen dieses ORM zu kämpfen. Am Ende tut es ja, was ich will, und es wurde irgendwo in dieser miesen Dokumentation geschrieben, aber ich stelle fest, dass ich eine weitere Stunde verliere, die ich nie bekommen werde. Jeder, der nhibernate und anschließend fließend nhibernate für postgresql verwendet, würde verstehen, was ich durchgemacht habe. Das ständige Gefühl "dieser Code ist nicht unter meiner Kontrolle" ist wirklich beschissen.

Ich zeige nicht mit den Fingern oder sage, dass sie schlecht sind, aber ich begann zu überlegen, was ich verrate, um CRUD in einem einzigen Ausdruck zu automatisieren. Heutzutage denke ich, ich sollte weniger ORM verwenden, vielleicht eine Lösung erstellen oder finden, die DB-Operationen auf ein Minimum beschränkt. Aber ich bin es nur. Ich glaube, einige Dinge in dieser ORM-Arena sind falsch, aber ich bin nicht fähig genug, um es auszudrücken, was nicht.

3
detay

Ich empfehle diese Lektüre für eine Liste der Nachteile von ORMs.

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Für mich selbst fand ich ORMs sehr nützlich für die meisten Anwendungen, die ich geschrieben habe!

/ Asger

3
asgerhallas

Die Laufzeitleistung ist der einzige wirkliche Nachteil, den ich mir vorstellen kann, aber ich denke, dies ist mehr als ein fairer Kompromiss für die Zeit, die ORM Ihnen das Entwickeln/Testen/etc erspart. In den meisten Fällen sollten Sie in der Lage sein, Datenengpässe zu lokalisieren und Ihre Objektstrukturen effizienter zu gestalten.

Ich habe Hibernate noch nie benutzt, aber eines ist mir bei einigen Standard-ORM-Lösungen aufgefallen: mangelnde Flexibilität. Ich bin mir sicher, das hängt davon ab, womit Sie arbeiten und was Sie damit tun müssen.

3
Oli

Es gibt zwei Aspekte von ORMs, die besorgniserregend sind. Erstens handelt es sich um Code, der von einer anderen Person geschrieben wurde, manchmal von Closed Source, manchmal von Open Source, aber von großem Umfang. Zweitens kopieren sie die Daten.

Das erste Problem verursacht zwei Probleme. Sie verlassen sich auf Code von Außenstehenden. Wir alle tun dies, aber die Entscheidung sollte nicht leichtfertig getroffen werden. Und was ist, wenn es nicht das tut, was Sie brauchen? Wann wirst du das entdecken? Sie wohnen in der Box, die Ihr ORM für Sie zeichnet.

Das zweite Problem ist das Festschreiben in zwei Phasen. Die relationale Datenbank wird in ein Objektmodell kopiert. Sie ändern das Objektmodell und es soll die Datenbank aktualisieren. Dies ist ein Zwei-Phasen-Commit und nicht das einfachste Debugging.

3
dacracot

Ich denke, dass die Verwendung eines ORM immer noch eine gute Idee ist. Vor allem in Anbetracht der Situation, die Sie geben. Es hört sich so an, als ob Sie in Bezug auf die DB-Zugriffsstrategien umso erfahrener sind, und ich würde die Verwendung eines ORMs erwähnen.

Es gibt kein Argument für # 1, da das Kopieren und Einfügen von Abfragen und das Hardcodieren in Text keine Flexibilität bietet, und für # 2 die meisten Orms die ursprüngliche Ausnahme umbrechen, das Verfolgen der generierten Abfragen usw. ermöglichen, so dass das Debuggen auch kein Hexenwerk ist.

Was die Validierung betrifft, wird die Verwendung eines ORM in der Regel auch die Entwicklung von Validierungsstrategien zusätzlich zu einer eingebauten Validierung erheblich vereinfachen.

Das Schreiben eines eigenen Frameworks kann mühsam sein und häufig werden Dinge übersehen.

EDIT: Ich wollte noch einen Punkt machen. Wenn Ihr Unternehmen eine ORM-Strategie anwendet, steigert dies den Wert des Unternehmens weiter, da Sie Richtlinien und Praktiken für die Verwendung und Implementierung entwickeln und jeder sein Wissen über das ausgewählte Framework vertiefen wird, wodurch eines der von Ihnen angesprochenen Probleme gemildert wird. Außerdem erfahren Sie, was funktioniert und was nicht, wenn Situationen auftreten, und am Ende sparen Sie viel Zeit und Mühe.

2
mattlant

Jeder ORM, auch ein "guter", wird mit einer Reihe von Annahmen geliefert, die sich auf die zugrunde liegenden Mechanismen beziehen, mit denen die Software Daten zwischen Ihrer Anwendungsebene und Ihrem Datenspeicher hin und her überträgt.

Ich habe festgestellt, dass das Umgehen dieser Annahmen bei mäßig anspruchsvollen Anwendungen in der Regel mehr Zeit in Anspruch nimmt, als nur eine einfachere Lösung zu schreiben, z. B .: Daten abfragen und neue Entitäten manuell instanziieren.

Insbesondere werden Sie wahrscheinlich Probleme bekommen, sobald Sie mehrspaltige Schlüssel oder andere mäßig komplexe Beziehungen verwenden, die nicht in den Anwendungsbereich der praktischen Beispiele fallen, die Ihnen Ihr ORM beim Herunterladen des Codes zur Verfügung gestellt hat.

Ich gebe zu, dass für bestimmte Arten von Anwendungen, insbesondere für Anwendungen mit einer sehr großen Anzahl von Datenbanktabellen oder dynamisch generierten Datenbanktabellen, der Auto-Magic-Prozess eines ORM nützlich sein kann.

Ansonsten zur Hölle mit ORMs. Ich halte sie jetzt im Grunde für eine Modeerscheinung.

1
Mason Houtz