LINQ to SQL: Anhängen oder Nicht anhängen
Ich habe also eine wirklich harte Zeit herauszufinden, wann ich an ein Objekt anhängen sollte und wann ich mich nicht an ein Objekt anheften sollte. Das erste, was zuerst ist, hier ist ein kleines Diagramm meines (sehr vereinfachten) Objektmodells.
In meiner DAL erzeuge ich bei jeder datenbezogenen Operation einen neuen DataContext. Sagen wir zum Beispiel, ich möchte einen neuen Benutzer speichern. In meiner Business-Schicht erstelle ich einen neuen Benutzer.
%Vor%Jetzt möchte ich speichern diesen Benutzer.
%Vor%Neato! Hier ist meine Speicherlogik:
%Vor%Also, hier sind wir. Sie werden bemerken, dass ich das Bit, an dem der DataContext an die Organisation angehängt ist, auskommentiert habe. Wenn ich an die Organisation anhefte, bekomme ich die folgende Ausnahme:
NotSupportedException: Es wurde versucht, eine Datei anzuhängen oder hinzuzufügen Entität, die nicht neu ist, vielleicht haben wurde von einem anderen DataContext geladen. Dies wird nicht unterstützt.
Hmm, das geht nicht. Lassen Sie mich es versuchen ohne Anfügen (d. H. Kommentar aus dieser Zeile über das Anhängen an die Organisation).
DuplicateKeyException: Eine Entität mit einem bereits vorhandenen Schlüssel kann nicht hinzugefügt werden in Benutzung.
WHAAAAT? Ich kann nur annehmen, dass dies versucht, eine neue Organisation einzufügen, die offensichtlich falsch ist.
Also, was ist der Deal Leute? Was soll ich machen? Was ist der richtige Ansatz? Es sieht so aus, als ob L2S dies etwas schwieriger macht, als es sein sollte ...
BEARBEITEN: Ich habe gerade bemerkt, dass ich, wenn ich versuche, die ausstehende Änderungsmenge (dataContext.GetChangeSet ()) zu betrachten, dieselbe NotSupportedException erhalte, die ich bereits beschrieben habe !! Was zum Teufel, L2S?!
3 Antworten
Es funktioniert vielleicht nicht genau so unter der Haube, aber hier ist die Art, wie ich es konzeptioniere: Wenn Sie ein Objekt aus einem DataContext aufrufen, verfolgt Linq die Änderungen an diesem Objekt mit der Zeit, damit es weiß, was zurück zu speichern, wenn Sie Änderungen übermitteln. Wenn du diesen ursprünglichen Datenkontext verlierst, hat das von ihm beschworene Linq-Objekt nicht die Geschichte dessen, was sich seit dem Zeitpunkt, als es aus der Datenbank abgerufen wurde, darin geändert hat.
Zum Beispiel:
%Vor%Da das Benutzerobjekt aus dem Datenkontext aufgerufen wurde, hat es alle Änderungen an "u" verfolgt und weiß, wie diese Änderungen an die Datenbank übermittelt werden.
In Ihrem Beispiel hatten Sie ein Benutzerobjekt, das irgendwo gespeichert wurde (oder von woanders übergeben wurde und nicht den ursprünglichen DataContext hat, von dem es aufgerufen wurde). In diesem Fall müssen Sie sie an den neuen Datenkontext anhängen.
%Vor%Da die Beziehung zwischen Benutzer und Organisation nur eine GUID (OrganizationId) in Ihrem Datenmodell ist, müssen Sie nur das Benutzerobjekt anhängen.
Ich bin mir nicht sicher über Ihren Gerüstcode, aber vielleicht so etwas:
%Vor%So wird "attach" verwendet, wenn Sie ein Objekt aus der Datenbank übernehmen, es trennen (z. B. indem Sie es irgendwo anders über einen Webservice verteilen) und es wieder in die Datenbank einfügen möchten. Rufen Sie statt .Attach () stattdessen .InsertOnSubmit () auf. Sie sind fast konzeptionell, Sie verwenden nur die falsche Methode, um zu tun, was Sie wollen.
Ich habe einen großen Tisch mit mehr als 400 Spalten benutzt. Nein, ich werde das alles abbilden und testen!
Holen Sie das ursprüngliche Objekt aus der Datenbank und hängen Sie es an das geänderte Objekt an. Stellen Sie nur sicher, dass das zurückkommende Objekt vollständig belegt ist, andernfalls überschreibt es die DB mit Leerzeichen!
Oder Sie können das ursprüngliche GET in den Speicher kopieren und an einer korrekten Kopie (nicht nur einer Referenz) des MOdels arbeiten, dann das Original und das geänderte einlesen, anstatt es wie im Beispiel zu erhalten. Dies ist nur ein Beispiel dafür, wie es funktioniert.
%Vor%Tags und Links c# linq-to-sql