Ich bin gerade dabei, ein neues Projekt zu starten und die Geschäftsobjekte und den Datenzugriff zu erstellen. Ich benutze nur einfache alte clr-Objekte und keine Orms. Ich habe zwei Klassenbibliotheken erstellt: 1) Business Objects - hält alle meine Business-Objekte, alle diese Objekte sind leicht mit nur Eigenschaften und Geschäftsregeln. 2) Repository - dies ist für alle meine Datenzugriff.
Die Mehrheit meiner Objekte wird eine Kinderliste haben und meine Frage ist, was der beste Weg ist, um diese Werte zu laden, da ich keine unnötigen Informationen zurückbringen will, wenn ich es nicht brauche.
Ich habe darüber nachgedacht, wenn ich "get" in der untergeordneten Eigenschaft verwende, um zu prüfen, ob es "null" ist, und wenn es mein Repository aufruft, um die untergeordneten Informationen zu erhalten. Dies hat zwei Probleme von dem, was ich sehen kann: 1) Das Objekt "weiß", wie man sich selbst erhält Ich würde lieber keine Datenzugriffslogik im Objekt halten. 2) Dies erforderte, dass sich beide Klassen gegenseitig referenzierten, was im visuellen Studio einen zirkulären Abhängigkeitsfehler auslöst.
Hat jemand irgendwelche Vorschläge, wie man dieses Problem oder irgendwelche Empfehlungen zum Layout meines Projekts überwinden kann und wo es verbessert werden kann?
Danke
Nachdem ich mir die Antworten und weitere Untersuchungen angeschaut habe, fand ich einen Artikel, der Delegaten für das Lazy Loading verwendet. Dies bot eine einfachere Lösung als die Verwendung von Proxies oder die Implementierung von NHibernate.
Hier ist die link zu dem Artikel.
Dazu müssen Sie Schnittstellen programmieren (Abstraktionen über Implementierungen) und / oder Ihre Eigenschaften virtuell deklarieren. Dann gibt Ihr Repository ein Proxy-Objekt für die Eigenschaften zurück, die träge geladen werden sollen. Die Klasse, die das Repository aufruft, ist nicht klüger, aber wenn sie versucht, auf eine dieser Eigenschaften zuzugreifen, ruft der Proxy die Datenbank auf und lädt die Werte.
Ehrlich gesagt, ich denke es ist Wahnsinn, zu versuchen, das selbst zu implementieren. Es gibt großartige, erprobte Lösungen für dieses Problem, die von den größten Köpfen von .NET entwickelt und verfeinert wurden.
Um das Proxying durchzuführen, können Sie Castle DynamicProxy verwenden, oder Sie können NHibernate und lassen Sie es alle Proxying und Lazy Loading für Sie behandeln (es verwendet DynamicProxy). Sie erhalten eine bessere Leistung als von Hand gerollt Implementierungen, garantiert.
NHibernate wird sich nicht mit Ihren POCOs anlegen - keine Attribute, keine Basisklassen; Sie müssen die Mitglieder nur virtuell markieren, um die Proxy-Generierung zu ermöglichen.
Einfach gesagt, ich würde es überdenken, ein ORM zu verwenden, besonders wenn Sie dieses faule Laden wollen; Sie müssen Ihre POCOs nicht aufgeben.
Wenn Sie Entity Framework 4.0 verwenden, haben Sie Unterstützung für POCOs mit verzögertem Laden & amp; ermöglicht Ihnen, ein generisches Repository für den Datenzugriff zu schreiben.
Es gibt Unmengen von Artikeln online über generische Repository-Muster mit EF 4.0
HTH.
Sie können das zirkuläre Abhängigkeitsproblem umgehen, wenn Ihr verzögerter Ladecode das Repository zur Laufzeit lädt ( Activator.CreateInstance oder etwas Ähnliches) und dann die entsprechende Methode über Reflektion aufruft. Natürlich gibt es mit der Reflexion verbundene Leistungseinbußen, die sich jedoch bei den meisten Lösungen oft als unbedeutend erweisen.
Eine andere Möglichkeit, dieses Problem zu lösen, besteht darin, einfach zu einer einzelnen DLL zu kompilieren - hier können Sie Ihre Ebenen logisch unter Verwendung verschiedener Namespaces trennen und Ihre Klassen dennoch mithilfe verschiedener Verzeichnisse organisieren.
Tags und Links c# design-patterns repository data-access-layer