Was ist die Best Practice für Persistenz im Moment?

Question

Ich komme aus einem Java-Hintergrund.

Aber ich möchte eine plattformübergreifende Perspektive darüber, was Best Practice für persistente Objekte gilt.

So wie ich es sehe, gibt es 3 Lager:

• ORM Lager
• direkte Abfrage Lager z.B. JDBC/DAO, iBatis
• LINQ Lager

Haben die Leute immer noch handcode Abfragen (unter Umgehung ORM)? Warum, unter Berücksichtigung der Möglichkeiten, die über JPA, Django, Rails verfügbar sind.

Answer 1

Es gibt keine Best Practice für Persistenz (obwohl die Anzahl der Leute, die schreien, dass ORM die beste Praxis ist, könnte dazu führen, dass Sie etwas anderes glauben). Die einzige bewährte Methode besteht darin, die Methode zu verwenden, die für Ihr Team und Ihr Projekt am besten geeignet ist.

Wir verwenden ADO.NET und gespeicherte Prozeduren für den Datenzugriff (obwohl wir einige Helfer haben, die es sehr schnell schreiben wie SP-Klasse-Wrappergeneratoren, einen IDataRecord zu Objekt-Übersetzer und einige Prozeduren höherer Ordnung, die gängige Muster einkapseln und Fehlerbehandlung).

Es gibt eine Menge Gründe dafür, auf die ich hier nicht eingehen werde, aber es genügt zu sagen, dass es sich um Entscheidungen handelt, die für unser Team funktionieren und mit denen unser Team einverstanden ist. Was am Ende des Tages zählt.

Answer 2

Ich lese gerade über persistente Objekte in .net. Daher kann ich keine Best Practice anbieten, aber vielleicht können meine Einsichten Ihnen etwas bringen. Bis vor ein paar Monaten habe ich immer handcodierte Abfragen verwendet, eine schlechte Angewohnheit aus meinen ASP.classic Tagen.

Linq2SQL - Sehr leicht und einfach auf Geschwindigkeit zu bringen. Ich mag die stark typisierten Abfragemöglichkeiten und die Tatsache, dass SQL nicht auf einmal ausgeführt wird. Stattdessen wird es ausgeführt, wenn Ihre Abfrage bereit ist (alle angewendeten Filter), sodass Sie den Datenzugriff von der Filterung der Daten trennen können. Mit Linq2SQL kann ich auch Domänenobjekte verwenden, die von den Datenobjekten, die dynamisch generiert werden, getrennt sind. Ich habe Linq2SQL nicht in einem größeren Projekt ausprobiert, aber bisher scheint es vielversprechend. Oh, es unterstützt nur MS SQL, was eine Schande ist.

Entity Framework - Ich spielte ein bisschen herum und mochte es nicht. Es scheint alles für mich tun zu wollen und es funktioniert nicht gut mit gespeicherten Prozeduren. EF unterstützt Linq2Entities, was wiederum stark typisierte Abfragen erlaubt. Ich denke, dass es auf MS SQL beschränkt ist, aber ich könnte falsch liegen.

SubSonic 3.0 (Alpha) - Dies ist eine neuere Version von SubSonic, die Linq unterstützt. Das Tolle an SubSonic ist, dass es auf Vorlagendateien (T4-Vorlagen, in C# geschrieben) basiert, die Sie leicht ändern können. Wenn Sie möchten, dass der automatisch generierte Code anders aussieht, ändern Sie ihn einfach :). Ich habe bisher nur eine Vorschau versucht, werde aber heute das Alpha betrachten. Schau mal hier SubSonic 3 Alpha. Unterstützt MS SQL, unterstützt aber bald Oracle, MySql usw.

Bis jetzt ist meine Schlussfolgerung, Linq2SQL zu benutzen, bis SubSonic bereit ist und dann zu diesem zu wechseln, da SubSonics Vorlagen viel mehr Anpassung erlaubt.

Answer 3

Es gibt mindestens einen anderen: System Prevalence.

Soweit ich sagen kann, hängt das, was optimal für Sie ist, sehr von Ihren Umständen ab. Ich konnte sehen, wie für sehr einfache Systeme, direkte Abfragen immer noch eine gute Idee sein könnte. Außerdem habe ich gesehen, dass Hibernate mit komplexen Legacy-Datenbankschemata nicht gut funktioniert. Daher ist die Verwendung eines ORM möglicherweise nicht immer eine gültige Option. Die Systemprävalenz sollte unglaublich schnell sein, wenn Sie genug Speicher haben, um all Ihre Objekte in den Arbeitsspeicher zu packen. Ich weiß nichts über LINQ, aber ich nehme an, es hat auch seinen Nutzen.

Wie so oft lautet die Antwort: Kennen Sie eine Vielzahl von Tools für den Job, damit Sie den für Ihre spezifische Situation am besten geeigneten verwenden können.

Answer 4

Die beste Vorgehensweise hängt von Ihrer Situation ab.

Wenn Sie Datenbankobjekte in Tabellenstrukturen mit einer sinnvollen Struktur benötigen (also eine Spalte pro Feld, eine Zeile pro Entity usw.), benötigen Sie eine Art Translation Layer zwischen Objekten und der Datenbank. Diese fällt in zwei Lager:

• Wenn es keine Logik in der Datenbank (nur Speichern) und Tabellen zugeordnet wird, um Objekte gut, dann kann eine ORM-Lösung bietet ein schnelles und zuverlässiges Persistenz-System. Java-Systeme wie Toplink und Hibernate sind dafür ausgereifte Technologien.

• Wenn es ist Datenbanklogik in Persistenz beteiligt ist, oder Ihr Datenbank-Schema von Ihrem Objektmodell treibt deutlich, Stored Procedures umwickelt von Data Access Objects (mit weiteren Mustern, wie Sie mögen) ist ein wenig komplizierter als ORM aber flexibler.

Wenn Sie nicht brauchen, strukturierte Speicherung (und Sie müssen wirklich sicher sein, dass Sie dies nicht tun, da es zu den bestehenden Daten einzuführen, ist kein Spaß), können Sie Objektdiagramme serialisierten speichern direkt in die Datenbank, viel Komplexität umgeht.

Answer 5

Ich ziehe es vor, meine eigene SQL zu schreiben, aber ich verwende alle meine Refactoring-Techniken und andere "gute Sachen", wenn ich dies tue.

Ich habe Datenzugriffsschichten, ORM-Code-Generatoren, Persistenzschichten, UnitOfWork-Transaktionsverwaltung und viele SQL geschrieben. Ich habe dies in Systemen aller Formen und Größen getan, einschließlich äußerst leistungsstarker Daten-Feeds (vierzigtausend Dateien mit insgesamt 40 Millionen Transaktionen pro Tag, die jeweils innerhalb von zwei Minuten in Echtzeit geladen werden).

Das wichtigste Kriterium ist Schicksal, als Kontrolle davon. Lassen Sie Ihr ORM-Tool niemals ein Hindernis sein, um Ihre Arbeit zu erledigen, oder eine Entschuldigung dafür, es nicht richtig zu machen. Letztendlich ist alles gute SQL handgeschrieben und handsigniert, aber einige anständige Tools können Ihnen helfen, schnell einen guten ersten Entwurf zu erhalten.

Ich behandle dieses Problem auf die gleiche Weise wie ich meine UI-Design. Ich schreibe alle meine UIs direkt in Code, aber ich benutze vielleicht einen visuellen Designer, um einige wesentliche Elemente zu modellieren, die ich im Sinn habe, dann reiße ich den erzeugten Code auseinander, um meinen eigenen zu starten.

Verwenden Sie also ein ORM-Tool in jeder seiner Manifestationen als eine Möglichkeit, ein anständiges Beispiel zu erhalten - schauen Sie sich an, wie es viele der auftretenden Probleme löst (Schlüsselgenerierung, Assoziationen, Navigation usw.). Reißen Sie seine Ausgabe auseinander, machen Sie sie zu Ihrer eigenen, und verwenden Sie sie dann wieder.