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

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 zum Schreiben machen, wie zum Beispiel Wrappergeneratoren der Klasse SP, einen IDataRecord zu Objekt-Übersetzer und einige Prozeduren höherer Ordnung, die gängige Muster enthalten 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.

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 von meinen ASP.classic Tagen.

Linq2SQL - Sehr leicht und einfach zu erreichen. 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 habe ein bisschen damit herumgespielt und es nicht gemocht. 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, es ist auf MS SQL beschränkt, 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. Schauen Sie sich hier SubSonic 3 Alpha an. 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.

Es gibt mindestens einen anderen: Systemprävalenz .

Soweit ich sagen kann, hängt das, was für Sie optimal 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.

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 fallen in zwei Lager:

• Wenn in der Datenbank keine Logik vorhanden ist (nur Speicher) und Tabellen den Objekten gut zugeordnet werden, kann eine ORM-Lösung ein schnelles und zuverlässiges Persistenzsystem bereitstellen. Java-Systeme wie Toplink und Hibernate sind ausgereifte Technologien dafür.

• Wenn die Datenbanklogik an der Persistenz beteiligt ist oder Ihr Datenbankschema sich deutlich von Ihrem Objektmodell entfernt hat, werden gespeicherte Prozeduren von Datenzugriffsobjekten (mit weiteren Mustern, wie Sie möchten) umschlossen ein bisschen mehr beteiligt als ORM, aber flexibler.

Wenn Sie keinen strukturierten Speicher benötigen (und Sie müssen wirklich sicher sein, dass Sie das nicht tun, da die Einführung in vorhandene Daten keinen Spaß macht), können Sie serialisierte Objektgraphen direkt speichern in der Datenbank unter Umgehung einer Menge Komplexität.

Ich schreibe lieber mein eigenes SQL, aber ich verwende alle meine Refactoring-Techniken und andere "gute Sachen", wenn ich das tue.

Ich habe Datenzugriffsschichten, ORM-Codegeneratoren, Persistenzschichten, UnitOfWork-Transaktionsverwaltung und viele SQL-Anweisungen geschrieben. Ich habe das 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 Echtzeit geladen wurden).

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

Verwenden Sie also ein ORM-Tool in einer seiner Erscheinungsformen, um 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 erneut.