In unserer mehrschichtigen Anwendung greifen wir über WCF-Aufrufe auf die Datenbank zu. Wir erstellen und disponieren Kontexte pro Anfrage. Auch wir verwenden den POCO-Ansatz.
Meine Frage ist, dass es im reinen POCO-Modell (vollständig persistent ignorante POCOs) möglich ist, die Änderungen zu verfolgen, während wir Kontext pro Anfrage erstellen und ablegen (da der vorherige Kontext in diesem Service-Aufruf enthalten ist)? Wenn ja, wie geht EF mit dieser Situation um? Soweit ich das sehe, können 2 Mechanismen (Snapshot-basierte Änderungsverfolgung und Benachrichtigungsbasierte Änderungsverfolgung mit Proxies) nicht damit umgehen? Wenn nicht, wie sollten wir mit dem Kontext umgehen, damit wir die Änderungen verfolgen können?
Leider finden Sie in Entity Framework v1.0 keine einfache Lösung dafür. Es gab viel Diskussion und wenig Auflösung. Es ist eines der vielen bekannten Probleme mit EF v1.0 und auf die eine oder andere Art wirst du am Ende viel Code schreiben müssen, um damit umzugehen.
In .NET 4.0 hat das ADO.NET-Team Self-Tracking-Entitäten , um genau dieses Problem anzugehen.
Ich würde sagen:
Verwenden Sie keine Self-Tracking-Entitäten in einer reinen SOA-Umgebung: Die Self-Tracking-Entitäten funktionieren nur, wenn Ihre Kunden sie verwenden die generierten Proxy-Klassen.
Wenn Sie SOA nach dem Buch ausführen, können Sie Ihre Kunden nicht erwarten zu sein .Net oder noch mehr, .Net 4.0; Welches ist das einzige Szenario? in denen Self-Tracking-Entitäten funktionieren. Ihre Dienste werden sein nutzlos für andere Kunden.
Nur meine 2 Cent, Grüße, Koen
Self-Tracking Entities löst dieses Problem tatsächlich, wenn Sie das Modell mit dem Client teilen können, anstatt Metadaten zu verwenden, die von der Referenz generiert wurden.
Entwerfen Sie die STEs und verweisen Sie sie vom Client aus. Sie haben dann Zugriff auf das Tracking, das vom Kontext getrennt ist.
Tags und Links wcf entity-framework poco soa change-tracking