Nutzung von Self-Tracking-Einheiten in ASP.NET über mehrere Beiträge

Question

Ich habe eine einfache Anforderung (so dachte ich ...!)

ich ein Modell, das von Ordnung, Orderline, Produkt besteht.

Ich möchte einen Auftrag erstellen und OrderLines (jede OrderLine für ein Produkt) hinzufügen. Ich erstelle den Auftrag und füge neue OrderLines hinzu. Zwischen Posts speichere ich die Order-Entität in Session (oder ViewState). Nur damit Sie wissen, ich habe Unterstützung für die binäre Serialisierung hinzugefügt, die gut funktioniert.

Die Beziehung ist daher Auftrag> AuftragLinie (n)> Produkt (e).

Möglicherweise haben Sie bereits erraten, was das Problem ist - dass ich bei SaveChanges() das übliche 'AcceptChanges kann nicht fortgesetzt werden, weil die Schlüsselwerte des Objekts mit einem anderen Objekt im ObjectStateManager in Konflikt stehen.' Error.

Ich habe auf eine Reihe von Artikeln online verwiesen, aber keiner scheint diesen Fall zu behandeln (wo ich die Beziehung zwischen mehr als zwei Entitäten habe), z. http://blogs.msdn.com/b/diego/archive/2010/10/06/self-tracking-entities-applychanges-and-duplicate-entities.aspx.

Dies muss sicherlich eine sehr häufige Anforderung sein? Gibt es jemanden da draußen, der dasselbe mit Entity Framework macht (und ohne DTOs usw. zu verwenden)?

Prost - Hilfe! :)

Nick

Answer 1

Dies ist, was ich ...

Verwenden Sie die EF generierten Einheiten und Verbänden zu tun beschlossen (NICHT STEs - Sie sind richtig Nick) den Auftrag zu bauen. Schließen Sie immer Fremdschlüssel ein.

Setzen Sie MergeOption auf KEINE VERFOLGUNG, d. H. Getrennt.

Speichern Sie relevante Entitäten in SESSION zwischen Posts/Seitenanforderungen, während der Benutzer die Bestellung aufbaut.

Wichtig: Beim Zuordnen von untergeordneten Entitäten (z. B. OrderLines) werden keine vorhandenen untergeordneten Entitäten durch Relation zugeordnet, sondern die FK-ID. Verwenden Sie also nicht OrderLine.Product = product, sondern OrderLine.Product_Id = product.Id. Dies behebt Probleme, bei denen mehrere Entitäten aus verschiedenen Kontexten existieren.

Wenn der Auftrag abgeschlossen und bereit zum Speichern ist, fügen Sie den Kontext und SaveChanges hinzu.

-

bei der Bearbeitung von bestehenden Ordnung ...

Set MergeOption auf keine Sendungsverfolgung.

Speichern Sie relevante Entitäten in SESSION zwischen Posts/Page Requests, während der Benutzer die Bestellung bearbeitet.

Ich verwende meinen eigenen Entitätsstatusindikator, damit ich aufzeichnen kann, ob eine Entität hinzugefügt, geändert oder gelöscht wird, wenn sie losgelöst wird.

Wenn die Änderungen abgeschlossen und bereit zum Speichern sind, hängen Sie den Kontext an, bearbeiten Sie die Änderungen (setzen Sie ObjectState auf MODIFIED usw.) und SaveChanges.

-

Works einen Traum - kurzlebig Kontext (UOW) - keine Ansicht Modell oder DTO (einfach die Entity-Klassen verwenden) - kein komplexer Code (detatching/Anbringen Diagramme usw.).

Hinweis: Wird nicht in VIEWSTATE gespeichert. Ich muss das untersuchen, da ich von InProc zu SQL wechseln möchte. Werde Dich auf dem Laufenden halten.

Vielleicht habe ich etwas verpasst, aber ich habe viel Zeit damit verbracht, mögliche Lösungen dafür zu erforschen.

Answer 2

Ich höre das viel "NICHT STEs" aber warum nicht? Ich habe eine Multi-Tier-App mit WinForms-, WPF- und ASP.Net-Komponenten und verwende meine STEs für alle Ebenen. Stellen Sie in ASP sicher, dass Sie Ihren STE zwischen Views und Änderungen in ViewState \ SessionState beibehalten und Ihr Code sollte gut funktionieren.

Ich habe Entitäten, die viele Ebenen von Beziehungen ohne Problem haben, gibt es kleine Beispiele dafür, weil die Prinzipien identisch sind, egal wie viele Ebenen. Ich empfehle, mit STEs fortzufahren, wenn Sie genügend Zeit und Geduld haben, um Ihre Skripte für Ihre Bedürfnisse zu nutzen. Ich habe jetzt ein solides Framework basierend auf STEs, das ich in all meinen Anwendungen verwende.

STE die mir erlauben, Daten in Sharepoint zuzugreifen (.NET 3.5), wenn das Modell und Management-App tatsächlich 4.0 Net ist, dies ist eines der häufig übersehen Vorteile von STEs vs Entity Framework.

Siehe Self-Tracking Entities: ApplyChanges and duplicate entities um Hilfe zu Ihrem speziellen Problem.