.NET Object Persistence Optionen

Question

Ich habe eine Frage, die ich gerade nicht fühle, wie ich eine befriedigende Antwort für entweder gefunden habe, oder ich habe nicht an der richtigen Stelle gesucht.

Unser System wurde ursprünglich mit .NET 1.1 erstellt (die Projekte unterstützen jetzt alle 3.5) und alle Entitäten werden in der Datenbank mit gespeicherten Prozeduren und einem "SQLHelper" mit den Standardmethoden ExecuteReader, ExecutreNonQuery persistent gespeichert.

Also, was geschieht in der Regel ist, dass wir unsere Einheiten zum Beispiel Benutzer- und Rollen haben werden, und wir werden eine andere Klasse namens UserIO, die die Objekte Datenbank mit Methoden wie weiter besteht:

static UserIO.SaveUser(User user) 

Der Grund für die separate IO-Datei ist die IO getrennt von der Einheit zu halten, aber es ist nicht mehr zufrieden stellend nur anrufen ?:

User.Save() 

Vielleicht bin ich falsch, aber es fühlt sich einfach nicht richtig an diese haben " IO "Dateien verstreut über den ganzen Ort. Also denke ich darüber nach, andere Optionen für Ausdauer zu suchen, und ich fragte mich, wo der beste Ort zum Starten wäre. Ich habe in der Vergangenheit Datensätze verwendet, hatte aber einige gemischte Erfahrungen, insbesondere mit ihrer Leistung. Ich weiß, dass LINQ jetzt schon da ist, aber ich habe gehört, dass ich anstelle von LINQ das ADO.NET Entity Framework verwenden sollte, aber dann hat jemand anderes mir gesagt, dass das Entity Framework nicht ganz richtig ist und ich auf C# 4.0 warten sollte. Wenn das der Fall ist und mit C# 4.0 gleich um die Ecke sollte ich einfach weiter mit meiner "IO" -Datei Ansatz und starten Sie mit dem Entity Framework, wenn C# 4.0 endlich veröffentlicht wird. Oder gibt es vielleicht eine elegantere Klassenstruktur, die ich z. Teilklassen nutzen?

Ich sollte sagen, ich bin nicht dabei, den bereits vorhandenen Datenzugriff vollständig zu ersetzen, ich bin mehr mit den neuen Entitäten beschäftigt, die ich erstelle.

Es tut mir leid, wenn diese Frage ein wenig allgemein ist, aber ich habe nicht viele Leute um diese Art von Gedanken abzustoßen.

Answer 1

Ich habe Entity Framework 3.5 erfolgreich verwendet. Es gibt einige, die ich als Puristen bezeichnen würde, die der Meinung waren, dass das Entity Framework einige Regeln verletzt und nicht verwendet werden sollte.

Meiner Meinung nach sind die einzigen Regeln, die Ihnen wichtig sind, Ihre eigenen. Ich empfehle Ihnen, mit Entity Framework 3.5 zu experimentieren, da Sie es jetzt haben. Sobald Sie können, müssen Sie (und fast alle anderen) mit .NET 4.0 experimentieren. Der Release Candidate ist kostenlos verfügbar, es gibt also keinen Grund, nicht zu wissen, was verfügbar ist.

Es ist möglich, dass Sie die EF-Änderungen in 4.0 so sehr finden, dass Sie darauf warten möchten. Genauso ist es wahrscheinlich, dass Sie nicht warten müssen und von EF wie in Version 3.5 profitieren können. Ich habe, und ich bin sehr froh, dass ich nicht gewartet habe.

Answer 2

Es ist ein allgemeines Muster, ein Repository zu haben, das vom Modell getrennt ist. Der Name IO ist für ein solches Muster eindeutig, aber gültig. Abhängig davon, mit wem Sie sprechen (TDD Nüsse in den Sinn kommen), können Sie Flack für die Verwendung einer statischen Klasse bekommen.

Answer 3

Wenn Sie für objekt-relationale Mapping-Modelle suchen, können Sie in aussehen:

• NHibernate
• LLBLGen
• iBATIS

Es gibt auch eine längere Liste hier: http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#.NET

Für die allgemeine Frage, wie ein Objektmodell für die Persistenz zu entwerfen, hängt die Designauswahl von der Komplexität des Systems, der Erweiterbarkeit, die Sie benötigen, ob mehrere Persistenzspeicher (SQLServer, Oracle , Dateisystem usw.) und so weiter. Das Muster, das Sie beschreiben, sieht wie ein DataTansferObject (DTO) aus. Es ist ein üblicher Entwurf zum Trennen der Persistenzlogik von der Geschäftslogik.

Nebenbei bemerkt, ein allgemeines Prinzip des guten Systemdesigns ist die . Beim Aufbau eines Systems müssen Sie entscheiden, ob es sinnvoll ist, unterschiedliche Verantwortlichkeiten zu einer Klasse zusammenzufassen. Die Kombination von Verantwortlichkeiten kann ein System oft komplizieren und schwer lösbare Konstruktionskonflikte verursachen.

Answer 4

Eine Reihe von Klassen, die die Datenfunktionen implementieren, wird oft als Stufenprogrammierung bezeichnet. (http://en.wikipedia.org/wiki/N-tier). Durch die Trennung der Klassen, die auf die Datenebene zugreifen, erstellen Sie ein System, das wesentlich wartungsfreundlicher ist. Wenn Sie diese Funktionen in den Klassen zusammenführen, die die Geschäftsregeln in Ihrer Anwendung implementieren, würden Sie viele der Vorteile eines mehrstufigen Designs verlieren.

Die Datenzugriffsfunktionen in ihre eigenen Klassen zu spucken ist gut (3 Cheers für den Designer), aber sie überall verbreiten ist schlecht. Idealerweise wäre die Quelle für diese Funktionen nicht alle im selben Verzeichnis oder in derselben Datei (abhängig von der Projektgröße). Wenn sie alle zusammen sind, gewinnen Sie viele Vorteile. Wenn sie in (zufällige?) Bereiche aufgeteilt werden, wird der Zweck der Modularisierung dieses Codes nicht erfüllt.

Answer 5

Ein Muster, das ich ziemlich regelmäßig verwenden ist: Jedes Objekt hat die folgenden:

• Data Transfer Object (DTO) - Dies hält die durch Datensätze so klein wie möglich verwendeten Speicher.
• Business Object - Das nimmt die oben DTO als Konstrukteur zumindest - Diese auf der DTO jede Funktion ausführen soll, die
• CRUD/persistierendem Methoden in einem Repository-Klasse

Letztere kein CRUD Funktion ist kann auf zwei Arten erfolgen. Sie können eine große Repository-Klasse haben, die für Anwendungen/Komponenten mit nur wenigen Objekten geeignet ist, oder Sie können separate Repositories für jedes Objekt haben.

Werfen Sie einen Blick auf Rudy Lacovaras Blog. Er hat kürzlich eine Reihe von Beiträgen zum effizienten Datenzugriff mit einem ähnlichen Muster gemacht.