Gibt es gute Gründe, kein ORM zu verwenden?
Während meiner Ausbildung, die ich verwendet habe NHibernate für einige kleinere Projekte, die ich hauptsächlich programmiert und gestaltet auf eigene Faust. Jetzt, vor dem Start einige größere Projekt, die Diskussion aufkam, wie man design-Daten Zugriff hat und ob oder nicht, um eine ORM-Schicht. Als ich bin noch in meiner Ausbildung und mich selbst immer noch als Anfänger in der enterprise-Programmierung habe ich nicht wirklich versuchen, zu schieben, meiner Meinung nach, ist, dass die Verwendung eines Objekt-relationalen-mapper in die Datenbank Erleichterung der Entwicklung eine ganze Menge. Die anderen Programmierer im Entwicklerteam viel mehr Erfahrung als ich, so dass ich denke, ich werde nur tun, was Sie sagen. 🙂
Jedoch, ich verstehen nicht vollständig, zwei der wichtigsten Gründe für die nicht-Verwendung von NHibernate oder ein ähnliches Projekt:
- Kann man nur erstellen einer eigenen data-access-Objekte mit SQL-Abfragen und kopieren Sie diese Abfragen von Microsoft SQL Server Management Studio.
- Debugging ein ORM kann hart sein.
So, natürlich konnte ich nur auf meine Daten zugreifen Schicht mit einer Menge von SELECTs etc, aber hier vermisse ich den Vorteil von automatischen Verknüpfungen, lazy loading-proxy-Klassen und einen geringeren Wartungsaufwand, wenn eine Tabelle wird eine neue Spalte oder eine Spalte umbenannt wird. (Aktualisierung zahlreiche SELECTINSERT und UPDATE Abfragen vs. Aktualisierung der mapping-config und ggf. die Umgestaltung der business-Klassen und DTOs.)
Auch mit NHibernate, die Sie ausführen können, in unvorhergesehene Probleme, wenn Sie nicht wissen, der Rahmen sehr gut. Das könnte zum Beispiel sein, Vertrauen in die Table.hbm.xml hier legen Sie eine Zeichenfolge der Länge werden automatisch validiert. Jedoch, ich kann sich auch vorstellen, ähnliche bugs in einer "einfachen" SqlConnection-query data access layer.
Schließlich sind diejenigen Argumente, die oben erwähnt wird, wirklich ein guter Grund, nicht zu nutzen, ein ORM für eine nicht-triviale Datenbank-basierten enterprise-application? Gibt es wahrscheinlich auch andere Argumente, die Sie/ich verpasst haben könnte?
(Ich sollte wohl hinzufügen, dass ich denke, das ist wie die erste "große" .NET/C# - basierte Anwendung, die erfordert Teamarbeit. Gute Praktiken, die betrachtet werden als ziemlich normal auf Stack Overflow, wie unit testing oder continuous integration, sind nicht vorhandene hier bis jetzt.)
InformationsquelleAutor der Frage hangy | 2008-10-11
Du musst angemeldet sein, um einen Kommentar abzugeben.
Gab es eine explosion des Wachstums mit ORMs in den letzten Jahren und Ihre erfahrenen Mitarbeiter können immer noch denken, in der "jeder Datenbank-Aufruf sollte durch eine gespeicherte Prozedur" - Mentalität.
Warum würde ein ORM machen Dinge schwieriger zu Debuggen? Sie erhalten das gleiche Ergebnis, ob er kommt aus einer stored proc oder aus dem ORM.
Ich denke, der einzige wirkliche Nachteil, den ich denken kann, mit ein ORM ist, dass die Sicherheit Modell ist ein wenig weniger flexibel.
EDIT: ich nur re-Lesen Sie Ihre Frage und sieht Sie kopieren und einfügen von Abfragen in inline-sql. Das macht das security Modell das gleiche wie ein ORM, so würde es absolut keinen Vorteil gegenüber diesem Ansatz über ein ORM. Wenn Sie mit unparametrized Abfragen, dann wäre es tatsächlich ein Sicherheitsrisiko sein.
InformationsquelleAutor der Antwort Giovanni Galbo
Die kurze Antwort ist ja, es gibt wirklich gute Gründe. Als eine Angelegenheit von der Tat gibt es Fälle, wo Sie nur können einem ORM.
Case in point, ich arbeite für ein großes Unternehmen Finanzinstitut, und wir haben zu Folgen eine Menge von Sicherheits-Richtlinien. Zu den Regeln und Vorschriften, die auf uns gelegt, der einzige Weg, um das bestehen von audits zu halten, Zugriff auf Daten innerhalb von gespeicherten Prozeduren. Jetzt können einige sagen, dass ist einfach nur dumm, aber ehrlich ist es nicht. Mit einem ORM-tool heißt das tool/Entwickler kann das einfügen, auswählen, aktualisieren oder löschen, was auch immer er oder Sie will. Gespeicherte Prozeduren bieten viel mehr Sicherheit, speziell in Umgebungen, beim Umgang mit Kundendaten. Ich denke, dies wird der größte Grund ist zu prüfen. Sicherheit.
InformationsquelleAutor der Antwort Keith Elder
Den sweet spot der ORMs
ORMs sind nützlich für die Automatisierung der 95%+ der Abfragen, wo Sie anwendbar sind. Ihre Besondere Stärke ist, wo Sie haben eine Anwendung, die mit einem starken object model-Architektur und eine Datenbank, die spielt schön mit, dass Objekt-Modell. Wenn Sie dabei einen neuen zu bauen und haben eine starke Modellierung Fähigkeiten in Ihrem team haben, dann werden Sie wahrscheinlich zu bekommen gute Ergebnisse mit einem ORM.
Können Sie auch eine Handvoll Abfragen, die besser sind von hand gemacht. In diesem Fall haben Sie keine Angst zu schreiben, ein paar gespeicherte Prozeduren, um diese zu bewältigen. Auch, wenn Sie beabsichtigen zu portieren Ihrer app über mehrere DBMS-Plattformen der Datenbank abhängigen code in der Minderheit. Eingedenk der Tatsache, dass Sie brauchen, um zu testen Sie Ihre Anwendung auf jeder Plattform, auf der Sie beabsichtigen, Sie zu unterstützen, ein bisschen extra-Portierung für einige gespeicherte Prozeduren nicht gehen, um einen großen Unterschied machen, um Ihre TCO. Für eine erste Annäherung, 98% portable ist nur so gut wie 100% tragbar, und weit besser als verworren oder schlecht funktionierende Lösungen zu arbeiten, um die Grenzen eines ORM.
Ich habe gesehen der erste Ansatz funktioniert gut auf eine sehr große (100 von Mitarbeiter-Jahre) J2EE-Projekt.
Wo ein ORM ist vielleicht nicht die beste Passform
In anderen Fällen gibt es möglicherweise Ansätze, die entsprechend der Anwendung besser als ein ORM. Fowler ' s Patterns of Enterprise Application Architecture einen Abschnitt hat, auf Daten zugreifen Muster, die macht einen ziemlich guten job der Katalogisierung verschiedene Lösungsansätze. Einige Beispiele, die ich gesehen habe, Situationen, in denen ein ORM möglicherweise nicht anwendbar sind:
Auf eine Anwendung mit einem erheblichen legacy-code-Basis von gespeicherten Prozeduren, die Sie verwenden möchten, können eine funktionell orientierte (nicht zu verwechseln mit funktionalen Sprachen) data access layer zu wrappen der amtierende sprocs. Dabei wird die vorhandene (und daher getestet und debuggt) data access layer und Datenbank-design, die oft stellt einen ganz erheblichen Entwicklungs-und Testaufwand, und spart sich die Migration der Daten auf ein neues Datenbank-Modell. Es ist oft eine gute Möglichkeit Umhüllung Java Schichten rund um legacy-PL/SQL-code-Basen, oder re-targeting-rich-client VB, Powerbuilder oder Delphi-Anwendungen mit web-Schnittstellen.
Eine variation ist, wo Sie Erben ein Datenmodell, das ist nicht unbedingt gut geeignet, Oder mapping. Wenn (zum Beispiel) Sie schreiben eine Schnittstelle, die gefüllt oder extrahiert Daten aus einer fremden-interface können Sie besser arbeiten direkt mit der Datenbank.
Finanz-Anwendungen oder andere Arten von Systemen, in denen cross-system-Datenintegrität ist wichtiger, vor allem, wenn Sie mit komplexen, verteilten Transaktionen mit two-phase commit. Möglicherweise müssen micromanage Ihre Transaktionen besser als ein ORM ist in der Lage, Sie zu unterstützen.
High-performance-Anwendungen, wo Sie wollen, um wirklich zu optimieren Ihrer Datenbank zugreifen. In diesem Fall kann es vorzuziehen sein, die Arbeit auf einem niedrigeren Niveau.
Situationen, bei denen Sie über eine vorhandene data-access-Mechanismus, wie ADO.Net das ist 'gut genug' und spielt schön mit der Plattform von größerem nutzen als die ORM bringt.
Manchmal Daten einfach nur Daten - es kann der Fall (zum Beispiel), dass die Anwendung der Arbeit mit 'Transaktionen' eher als 'Objekte' und, das ist eine vernünftige Sicht auf die Domäne. Ein Beispiel HIERFÜR könnte ein Rechnungswesen-Paket, wo Sie haben Transaktionen mit konfigurierbaren Analyse-Felder. Während die Anwendung selbst basiert auf einer O-O-Plattform, es ist nicht gebunden an eine einzelne business domain Modell und möglicherweise nicht bewusst sein, viel mehr als GL-codes, Konten, Belegarten und ein halbes Dutzend Analyse-Felder. In diesem Fall wird die Anwendung nicht bewusst, ein business domain model als solches und ein Objekt-Modell (über die ledger-Struktur selbst) ist nicht relevant für die Anwendung.
InformationsquelleAutor der Antwort ConcernedOfTunbridgeWells
Erstens - die Verwendung eines ORM wird nicht machen Sie Ihren code einfacher zu testen, noch wird es zwangsläufig irgendwelche Vorteile eines Continuous Integration scenerio.
Meiner Erfahrung, während die Verwendung eines ORM können erhöhen die Geschwindigkeit der Entwicklung, die größten Probleme, die Sie angehen müssen, sind:
Lösungen sind:
Kommen auf Ihre Frage, die beiden Einwände, die Sie auflisten, eher wie Unwissenheit als alles andere.
Nicht in der Lage zu schreiben von SELECT-Abfragen per hand (die, wie ich vermute, ist, warum die copy-paste ist erforderlich) scheint darauf hinzudeuten, dass es eine dringende Notwendigkeit für einige SQL-Schulung.
Es gibt zwei Gründe, warum ich keine ORM:
Den üblichen rebuffs über ORMs (NHibernate) sind:
Geschwindigkeit
Gibt keinen Grund, warum die Verwendung eines ORM wäre langsamer als die hand, die verschlüsselten Daten Zugreifen. In der Tat, wegen dem caching und Optimierungen eingebaut, kann es schneller sein.
Ein guter ORM erzeugt eine wiederholbare Reihe von Abfragen, für die Sie optimieren Ihr schema.
Ein guter ORM wird auch ermöglichen eine effiziente recherche der zugehörigen Daten mit verschiedenen fetching-Strategien.
Komplexität
Wird mit Bezug auf die Komplexität, die mit einem ORM bedeutet weniger code, die in der Regel bedeutet weniger Komplexität.
Viele Menschen mit hand-SCHRIFTLICHEN (oder auch code generiert wird) Daten-Zugriff finden sich schreiben Ihren eigenen Rahmen über "low-level" Daten Zugriff Bibliotheken (wie das schreiben von helper-Methoden für die ADO.Net). Diese belaufen sich auf mehr Komplexität, und, schlimmer noch, Sie sind selten gut dokumentiert, oder auch getestet.
Wenn Sie auf der Suche, die speziell auf NHibernate, dann auf tools wie Fluent NHibernate und Linq To NHibernate dämpft auch die Lernkurve.
Die Sache, die mich über die ganze ORM-Debatte ist, dass die gleichen Leute, die behaupten, dass die Verwendung eines ORM wird zu schwer/langsam/was auch immer sind die gleichen Leute, die sind mehr als glücklich, die Verwendung von Linq To Sql oder Typisierte Datasets. Während der Linq To Sql ist ein großer Schritt in die richtige Richtung, es ist immer noch Lichtjahre hinter sich, wo einige der open-source-ORMs sind. Jedoch, die Rahmenbedingungen für beide Typisierte Datasets und Linq To Sql ist immer noch Ungeheuer Komplex, und mit Ihnen zu gehen, zu weit von der (Table=Class) + (basic CRUD) ist dummerweise schwer.
Mein Rat ist, dass, wenn am Ende des Tages, Sie nicht bekommen kann ein ORM, dann stellen Sie sicher, dass Ihre Daten zugreifen ist getrennt von dem rest des Codes, und dass Sie Folgen Sie der Gang Of Four die Beratung der Codierung, um eine Schnittstelle. Außerdem erhalten Sie eine Abhängigkeit Injection-framework zu tun, die mit der Verdrahtung.
(Wie ist das für ein rant?)
InformationsquelleAutor der Antwort David Kemp
Gibt es eine Vielzahl von gemeinsamen Probleme für die ORM-tools wie Hibernate sind ein Gott senden, und ein paar, wo es ist ein Hindernis. Ich weiß nicht genug über Ihr Projekt zu wissen, welche es ist.
Einem Ruhezustand der starken Punkte ist, dass Sie Dinge sagen, die nur 3 mal: jede Immobilie ist bereits in der Klasse, die .hbm.xml Datei und der Datenbank. Mit SQL-Abfragen, Ihre Eigenschaften sind in der Klasse, die Datenbank, die select-Anweisungen, insert-Anweisungen, update-Anweisungen, delete-Anweisungen, und all das marshalling und unmarshalling-code unterstützen Sie Ihre SQL-Abfragen! Das kann schnell chaotisch. Auf der anderen Seite, Sie wissen, wie es funktioniert. Sie können Debuggen. Es ist alles genau dort in Ihrer eigenen Persistenz-Schicht, nicht vergraben in den Eingeweiden eines 3rd-party-tool.
Überwintern könnte ein Aushängeschild für Spolsky ' s Gesetz der Leaky Abstraktionen. Holen Sie sich ein wenig abseits der ausgetretenen Pfade, und Sie müssen wissen, Tiefe interne Arbeitsweise von dem tool. Es kann sehr ärgerlich sein, wenn Sie wissen, könnten Sie der festen SQL in Minuten, aber dafür sind Sie stundenlang versucht zu überreden Ihren dang-tool in der Generierung von angemessenen SQL. Debuggen ist manchmal ein Albtraum, aber es ist schwer, die Menschen davon zu überzeugen, die noch nicht dort gewesen.
EDIT: vielleicht möchten Sie sich in iBatis.NET wenn Sie nicht aktiviert werden, um über NHibernate und Sie wollen die Kontrolle über Ihre SQL-Abfragen.
EDIT 2: Hier ist das große, rote Flagge, obwohl: "Guten Praktiken, die betrachtet werden als ziemlich normal auf Stack Overflow, wie unit testing oder continuous integration, sind nicht vorhandene hier bis jetzt." Also, diese "erfahrenen" Entwickler, was sind Sie erfahren in der Entwicklung? Ihre job-Sicherheit? Es klingt wie Sie vielleicht unter den Menschen, die nicht besonders daran interessiert, in das Feld, so lassen Sie Sie nicht töten, Ihr Interesse. Sie müssen die balance. Einen Kampf.
InformationsquelleAutor der Antwort Alan Hensel
Arbeitete ich an einem Projekt, bei dem nicht mit einem ORM war sehr erfolgreich. Es war ein Projekt, das
Die Zeit, die es gedauert hätte, um NHibernate arbeiten in horizontal partitionierten Struktur gewesen wäre, viel länger als die Zeit, die es dauerte, zu entwickeln, die ein super einfaches datamapper, der sich dessen bewusst war, unsere Partitionierungsschema...
So, in 90% der Projekte, an denen ich gearbeitet habe, auf ein ORM wurde, eine unschätzbare Hilfe. Aber es gibt einige sehr spezifische Situationen, wo ich sehen kann, nicht mit einem ORM als beste.
InformationsquelleAutor der Antwort Mike
Lassen Sie mich zunächst sagen, dass ORMs können Ihre Entwicklung machen das Leben leichter, wenn richtig integriert, aber es gibt eine Handvoll von Problemen, bei denen der ORM kann tatsächlich verhindern, dass Sie von der Erreichung Ihrer festgelegten Anforderungen und Ziele.
Habe ich festgestellt, dass bei der Gestaltung der Systeme, die schwere performance-Anforderungen, bin ich oft herausgefordert, Wege zu finden, um das system performant. Viele Male, die ich am Ende mit einer Lösung, die eine schwere schreib-performance-Profil (Bedeutung schreiben wir Daten viel mehr, als wir sind, die Daten zu Lesen). In diesen Fällen, möchte ich die Vorteile der Einrichtungen, die Datenbank-Plattform bietet zu mir, um zu erreichen, unsere performance-Ziele (es OLTP -, OLAP-nicht). Also wenn ich mit SQL-Server und ich weiß, ich habe eine Menge von Daten zu schreiben, warum sollte ich nicht verwenden, die eine bulk insert... naja, wie du vielleicht schon entdeckt, die meisten ORMS (ich weiß nicht, ob auch nur eines einzigen macht) nicht die Möglichkeit haben, um die Vorteile von Plattform-spezifischen Vorteile wie bulk insert.
Sollten Sie wissen, dass Sie können mischen Sie die ORM und nicht-ORM Techniken. Ich habe gerade festgestellt, dass es ein paar Grenzfälle, wo ORMs können nicht unterstützen, die Ihren Anforderungen und Sie haben zu arbeiten, um Sie für solche Fälle.
InformationsquelleAutor der Antwort Ajaxx
Für eine nicht-triviale Datenbank-basierte enterprise-Anwendung, gibt es wirklich keine Rechtfertigung, nicht mit einem ORM.
Features abgesehen:
gelöst wiederholt von großen communities oder Unternehmen mit bedeutenden
Ressourcen.
aus den debugging-Bemühungen, die Gemeinschaft oder Gesellschaft.
Etwas Perspektive in das argument, sollten die Vorteile der Verwendung von ADO.NET vs. schreiben Sie den code zum Parsen der tabular data stream selbst.
Habe ich gesehen, Unwissenheit, wie ein ORM rechtfertigen Entwickler Verachtung für ORMs Zum Beispiel: eager loading (etwas, das ich bemerkt, dass Sie nicht erwähnt). Stellen Sie sich vor Sie abrufen möchten eine Kunden-und alle Ihre Bestellungen, und für diejenigen, die alle der Bestellung-detail-Elemente. Wenn Sie verlassen sich auf lazy loading nur, Sie gehen Weg von Ihrem ORM Erfahrung mit der Meinung: "ORMs sind langsam." Wenn Sie lernen, wie Sie mit eager loading, den Sie in 2 Minuten mit 5 Zeilen code, was Ihre Kollegen nehmen einen halben Tag zu implementieren: eine Abfrage an die Datenbank und binden die Ergebnisse in eine Hierarchie von Objekten. Ein weiteres Beispiel wäre der Schmerz der manuellen schreiben von SQL-Abfragen zu implementieren paging.
Der möglichen Ausnahme der Verwendung eines ORM wäre, wenn diese Anwendung wurden ein ORM-framework zu übernehmen spezialisierte business-Logik Abstraktionen und entworfen, um wiederverwendet werden auf mehrere Projekte. Selbst wenn das der Fall ist, allerdings würden Sie schneller Annahme durch die Verbesserung einer bestehenden ORM mit diesen Abstraktionen.
Lassen Sie sich nicht die Erfahrung Ihrer Senioren-team-Mitglieder ziehen Sie in die entgegengesetzte Richtung der evolution in der informatik. Ich habe die Entwicklung beruflich seit 23 Jahren, und eine der Konstanten ist die Verachtung für die neue von der alten Schule. ORMs sind, um SQL-Code als C-Sprache wurde auf Montage, und Sie können darauf Wetten, dass die äquivalente zu C++ und C# sind auf dem Weg. Eine Zeile von new-school-code gleich 20 Zeilen von der alten Schule.
InformationsquelleAutor der Antwort DaveMorganTexas
Wenn Sie brauchen, um zu aktualisieren, 50000000 Datensätze. Setzen Sie ein flag oder was auch immer.
Versuchen, dies zu tun mit einem ORM ohne aufrufen einer gespeicherten Prozedur oder native SQL-Befehle..
Update 1 : Versuchen Sie, auch das abrufen eines Datensatzes mit nur ein paar seiner Felder. (Wenn Sie haben eine sehr "Breite" Tabelle). Oder ein Skalares Ergebnis. ORMs saugen zu.
UPDATE 2 : Es scheint, dass EF 5.0 beta verspricht batch-updates, aber dieses ist sehr hot news (2012, Januar)
InformationsquelleAutor der Antwort Andrei Rînea
Ich denke, dass vielleicht, wenn Sie größere Systeme, die Sie verwenden können, eine code-generator-tool wie CodeSmith anstelle eines ORM... vor kurzem fand ich dieses: Mitarbeiterin Framework erzeugt Gespeicherten Prozeduren von SQL Server und generiert auch Ihre business-Einrichtungen, Mapper, gateways, lazyload und all das Zeug in C#...check it out...es wurde geschrieben von einem team hier in Argentinien...
Ich denke, es ist in der Mitte zwischen der Codierung des gesamten data access layer und verwenden Sie ein ORM...
InformationsquelleAutor der Antwort pabloide86
Persönlich habe ich (bis vor kurzem) im Gegensatz zur Verwendung eines ORM, und verwendet, um mit dem schreiben eine data-access-layer, Kapselung aller SQL-Befehle. Das Hauptargument gegen ORMs war, dass ich mich nicht trauen die ORM-Implementierung zu schreiben, die genau die richtige SQL. Und die Beurteilung durch die ORMs ich verwendet, um zu sehen (meist PHP-Bibliotheken), ich glaube, ich war völlig richtig.
Nun, die meisten meiner web-Entwicklung mit Django, und ich fand das enthalten ORM wirklich bequem, und da die Daten-Modell ausgedrückt wird zuerst in Ihren Bedingungen, und erst später in der SQL, es funktioniert perfekt für meine Bedürfnisse. Ich bin sicher, es würde nicht allzu schwer sein, dieses zu übertreffen und Bedarf zu ergänzen, die mit der hand geschriebene SQL, aber für den CRUD-Zugriff ist mehr als genug.
Ich weiß nicht, wie NHibernate, aber ich denke, es ist auch "gut genug" für die meisten von, was Sie brauchen. Aber wenn die anderen Programmierer nicht Vertrauen; es wird ein prime suspect auf jeden Daten-bezogenen Fehler, so dass die überprüfung mehr langweilig.
Könnten Sie versuchen, die Einführung allmählich, an Ihrem Arbeitsplatz, den Fokus zuerst auf die kleinen "offensichtlich" - Anwendungen, wie einfache Zugriff auf Daten. Nach einer Weile, es könnte verwendet werden, auf Prototypen, und es könnte nicht ersetzt werden...
InformationsquelleAutor der Antwort Javier
Wenn es sich um eine OLAP-Datenbank (z.B. statische, schreibgeschützte Daten, die für reporting/analytics, etc.) dann ist die Implementierung eines ORM-framework nicht geeignet ist. Stattdessen mithilfe der Datenbank-native-data-access-Funktionen wie gespeicherte Prozeduren vorzuziehen wäre. ORMs sind besser geeignet für transaktionale (OLTP) - Systeme.
InformationsquelleAutor der Antwort Ray Vega
Laufzeit-performance ist der einzige Nachteil ich denken kann, aber ich denke, das ist mehr als ein fairer Kompromiss für die Zeit ORM spart man beim entwickeln/testen/etc. Und in den meisten Fällen sollten Sie in der Lage zu lokalisieren, Daten-Engpässe und ändern Sie Ihre Objekt-Strukturen effizienter zu sein.
Habe ich nicht verwendet Hibernate vor, aber eine Sache, die ich bemerkt haben, mit ein paar "off-the-shelf" ORM-Lösungen ist ein Mangel an Flexibilität. Ich bin mir sicher, dass dies hängt davon ab, auf dem Sie gehen und was Sie tun müssen.
InformationsquelleAutor der Antwort Oli
Gibt es zwei Aspekte des ORMs, sind quälend. Erstens sind Sie für den code von jemand anderen geschrieben worden, manchmal auch closed source, manchmal auch open source, aber sehr groß im Umfang. Die zweite, Sie kopieren die Daten.
Das erste problem, das verursacht zwei Probleme. Sie befinden sich auf Außenseiter-code. Wir alle tun dies, aber die Wahl, dies zu tun sollte nicht leichtfertig getroffen werden. Und was, wenn es nicht tun, was Sie brauchen? Wann werden Sie entdecken? Sie Leben im inneren der box, dass Ihr ORM zeichnet für Sie.
Das zweite problem ist eine von zwei phase-commit. Die relationale Datenbank kopiert wird, um ein Objekt-Modell. Ändern Sie das Objekt-Modell und es soll ja auch die Datenbank zu aktualisieren. Dies ist ein zwei-phase-commit und nicht die einfachste Sache zu Debuggen.
InformationsquelleAutor der Antwort dacracot
Empfehle ich 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 mein selbst, die ich gefunden habe, ORMs sehr nützlich für die meisten Anwendungen, die ich geschrieben habe!
/Asger
InformationsquelleAutor der Antwort asgerhallas
Die Erfahrung habe ich mit Hibernate ist, dass die Semantik sind subtil, und wenn es gibt Probleme, es ist ein bisschen schwer zu verstehen, was schief geht, ist unter der Haube. Ich habe von einem Freund gehört, dass oft eine beginnt mit Kriterien, dann muss ein bisschen mehr Flexibilität und Bedürfnisse HQL, und später bemerkt, dass, nachdem alle, raw-SQL benötigt wird (zum Beispiel Hibernate nicht haben union AFAIK).
Auch mit ORM, die Menschen leicht dazu neigen zu Häufig vorhandenen Zuordnungen/Modelle, was dazu führt, dass es ein Objekt mit vielen Parametern, die nicht initiliazed. So, nachdem die Abfrage innerhalb der Transaktion Hibernate macht zusätzliche Daten abrufen, die potenzielle verlangsamen. Auch traurig, die hibernate Modell-Objekt ist manchmal durchgesickert in die Sicht auf Architektur-Ebene, und dann sehen wir LazyInitializationExceptions.
Verwenden ORM, sollte man es richtig zu verstehen. Leider bekommt man leicht den Eindruck, dass es leicht ist, während es nicht.
InformationsquelleAutor der Antwort egaga
Nicht auf eine Antwort per se, möchte ich formulieren, ein Zitat, das ich kürzlich gehört habe. "Ein guter ORM ist, wie ein Yeti, alle reden über einen, aber niemand sieht es."
Wenn ich meine Hände auf ein ORM, normalerweise finde ich mich kämpfen mit den Problemen/Einschränkungen, die ORM. Am Ende, ja, es tut was ich will und es irgendwo geschrieben wurde, dass der miesen Dokumentation, aber ich finde mich zu verlieren, die eine oder andere Stunde werde ich nie bekommen. Wer verwendet nhibernate, dann fluent nhibernate auf postgresql verstehen würde, was ich schon durch. Ständiges Gefühl von "dieser code ist nicht unter meiner Kontrolle" ist wirklich beschissen.
Ich nicht mit dem Finger auf Sie oder sagen, dass Sie schlecht sind, aber ich begann nachzudenken, was ich gebe Weg nur zu automatisieren CRUD-in einem einzelnen Ausdruck. Heute denke ich, ich sollte verwenden ORM ' s weniger, vielleicht erstellen oder suchen Sie eine Lösung, die es ermöglicht, db-Operationen, mindestens. Aber es ist gerade mich. Ich glaube, einige Dinge sind falsch in dieser ORM-arena, aber ich bin nicht qualifiziert genug, um es auszudrücken, was nicht.
InformationsquelleAutor der Antwort detay
Ich denke, es gibt viele gute Gründe, nicht zu verwenden, ein ORM. In Erster Linie bin ich ein .NET-Entwickler und ich gerne kleben, in welchem das wunderbar .NET framework bereits auf mich. Es tut alles, was ich möglicherweise brauchen es zu. Indem wir dies tun, bleiben Sie mit einem mehr standard-Ansatz, und daher gibt es eine viel bessere chance, von einem anderen Entwickler am selben Projekt arbeiten die Straße hinunter in der Lage, pick up, was ist da und mit ihm laufen. Der Daten-Zugriff-Funktionen bereits zur Verfügung gestellt von Microsoft sind Recht geräumig, es gibt keinen Grund, um Sie zu verwerfen.
Ich habe ein professional developer für 10 Jahre, führen mehrere sehr erfolgreiche Millionen-dollar-Projekte, und ich habe nicht ein einziges mal eine Anwendung geschrieben, die benötigt werden, um in der Lage, wechseln Sie zu einer Datenbank. Warum würden Sie jemals wollen ein client, dies zu tun? Sorgfältig planen, wählen Sie die richtige Datenbank für das, was Sie brauchen und bleiben Sie dabei. Persönlich SQL Server in der Lage war, zu tun alles, was ich jemals tun musste. Es ist einfach und es funktioniert Super. Es gibt sogar eine Kostenlose version unterstützt bis zu 10GB Daten. Oh, und es funktioniert Super mit .NET.
Ich vor kurzem hatte, um die Arbeit an mehreren Projekten, die ein ORM wie die datalayer. Ich denke, es ist schlecht, und etwas extra ich musste lernen, wie man ohne jeden Grund. In der unglaublich seltenen Umstand, der Kunde hat ändern müssen, Datenbanken, hätte ich leicht überarbeitet, die gesamte "datalayer" in weniger Zeit, als ich damit verbracht habe, den Narren mit dem ORM-Anbietern.
Ehrlich gesagt, ich denke, es ist eine wirkliche Verwendung für ein ORM: Wenn Sie eine Anwendung wie SAP, die wirklich brauchen, die Fähigkeit, auf mehrere Datenbanken. Anders als Lösungsanbieter, ich sage meinen Kunden diese Anwendung ausgelegt ist diese Datenbank-und das ist, wie es ist. Wieder einmal, nach 10 Jahren und einer unzähligen Anzahl von Anwendungen, ist das nie ein problem gewesen.
Ansonsten denke ich, dass ORMs sind für Entwickler, die nicht verstehen, dass weniger mehr ist, und denke, je mehr Coole 3rd-party-tools, die Sie in der app, desto besser die app. Ich lasse Dinge wie diese, die schwer sterben uber-geeks, während ich Kurbel viel mehr großartige software in der Zwischenzeit, dass jeder Entwickler kann sich abholen und sofort produktiv sein.
InformationsquelleAutor der Antwort Danny
Ich denke, dass die Verwendung eines ORM ist immer noch eine gute Idee. Vor allem angesichts der situation, die Sie geben. Es klingt durch Ihren Beitrag werden Sie mehr erfahren, wenn es um die db-access-Strategien, und ich brachte mit ein ORM.
Gibt es kein argument für #1 das kopieren und einfügen von Abfragen und hardcoding im text gibt keine Flexibilität, und #2 die meisten orm s wickeln Sie die ursprüngliche Ausnahme, erlaubt die Verfolgung der generierten Abfragen, etc, also debugging ist nicht Rakete Wissenschaft.
Als für die Validierung, die Verwendung eines ORM wird in der Regel auch viel leichter, Zeit für die Entwicklung von validierungsstrategien, die auf einem eingebauten Validierung.
Schreiben Sie Ihre eigenen framework mühsam, und oft Dinge verpasst bekommen.
EDIT: ich wollte einen Punkt mehr. Wenn Ihr Unternehmen nimmt eine ORM-Strategie, das steigert seinen Wert, wie Sie entwickeln Richtlinien und Methoden für die Nutzung und Umsetzung, und jeder wird weiter zu verbessern Ihre Kenntnisse der Rahmenbedingungen gewählt, die Abmilderung eines der Themen, die Sie gebracht. Außerdem werden Sie lernen, was funktioniert und was nicht, wenn Situationen entstehen, und am Ende wird es sparen Sie viel Zeit und Mühe.
InformationsquelleAutor der Antwort mattlant
Jeder ORM, sogar ein "gut", kommt gesattelt mit einer bestimmten Anzahl von Annahmen, die in Bezug auf die zugrunde liegenden Mechanismen, die die software verwendet, um Daten hin und her zwischen Ihrem application layer und Ihre Daten speichern.
Habe ich festgestellt, dass für einigermaßen anspruchsvolle Anwendung, dass die Arbeit um diese Annahmen in der Regel nimmt mir mehr Zeit als nur das schreiben einer mehr straightfoward Lösung wie z.B.: - Abfrage der Daten und manuell erstellen neuer Einheiten.
In allem, sind Sie wahrscheinlich zu laufen in Probleme, sobald Sie einsetzen, multi-column keys oder andere mäßig komplexen Beziehungen, die fallen einfach nicht in den Anwendungsbereich des praktischen Beispiele, die Ihre ORM zur Verfügung gestellt, die Sie beim herunterladen der code.
Ich zugeben, dass für bestimmte Arten von Anwendungen, insbesondere solche, die eine sehr große Anzahl von Datenbank-Tabellen oder dynamisch generierten Tabellen der Datenbank, dass die auto-Magie Prozess von ein ORM kann nützlich sein.
Sonst, zur Hölle mit ORMs. Ich jetzt davon ausgehen, dass Sie im Grunde eine Modeerscheinung.
InformationsquelleAutor der Antwort Mason Houtz