DataContext-Methoden in LINQToSQL überschreiben

Question

Ich bin neu bei LINQToSQL. Gibt es eine Möglichkeit, die Methoden "InsertOnSubmit" oder "DeleteOnSubmit" der DataContext-Klasse für eine bestimmte Entität zu überschreiben?

Wie zum Beispiel habe ich eine Datenbanktabelle namens Kunden, die ein boolesches Feld "IsDeleted" hat, das gilt, wenn der Benutzer einen Kundendatensatz aus der Benutzeroberfläche löscht. Wenn ich das _myDataContext.Customers.DeleteOnSubmit (..) aufrufen werde, löscht es standardmäßig den Datensatz aus der Tabelle, den ich nicht möchte. Stattdessen möchte ich, dass es logisch gelöscht wird, indem Sie das Feld "IsDeleted" auf "True" setzen.

Eine Möglichkeit besteht darin, das Objekt abzurufen und die Update-Methode (statt Löschen) aufzurufen, nachdem der Eigenschaftswert festgelegt wurde. Das wird auch funktionieren, aber nur aus Neugier möchte ich wissen, ob die Standard-DataContext-Methoden (InsertOnSubmit, DeleteOnSubmit usw.) überschreibbar sind? Und wenn ja, wie?

Dank

Answer 1

Soweit ich weiß, kein sind sie nicht. Wenn du es nicht löschen willst ... rufe nicht delete auf! Doch einige andere Optionen:

• könnten Sie das Löschen einer gespeicherten Prozedur zuordnen, die nur die Flagge auf der Datenbank setzt
• Sie in der Lage sein kann SubmitChanges und Fix-Up-Änderungen (via GetChangetSet) außer Kraft zu setzen, bevor Rufen Sie base.SubmitChanges - aber ich bin zweifelhaft, ob dies eine gute Idee ist; Möglicherweise muss der Artikel zum Beispiel neu eingefügt werden.

Code:

partial class MyDataContext { 
    public override void SubmitChanges(ConflictMode failureMode) { 
     var delta = GetChangeSet(); 
     foreach(var record in delta.Deletes.OfType<Customer>()) { 
      Customers.InsertOnSubmit(record); 
      record.IsDeleted = true; 
     } 
     base.SubmitChanges(failureMode); 
    } 
} 

Natürlich, wenn es flexibler zu sein braucht man GetTable() (statt einer starren Customers Eigenschaft) verwenden möchten.

---

Aktualisierungen zu Ihrem Kommentar; Ich glaube ehrlich gesagt nicht, dass Sie es tun können an diesem Punkt; Das "10 Orte" -Ding ... IMO Sie sollten den Datenkontext hinter einer Repository-Schnittstelle sowieso verstecken, so dass alle 10 Orte eine Methode wie CreateUser aufrufen würden, die sich mit dem Datenkontext und der notwendigen Logik beschäftigt (vielleicht mit einem separate Business-Logik-Klasse, um einige der Regeln zu handhaben). Außerdem sollte die Eindeutigkeit normalerweise auf Datenbankebene behandelt werden (über eine Einschränkung), da Bedenken hinsichtlich der Nebenläufigkeit bestehen.

Aber das zu tun, was Sie wollen, bevor Sie versuchen, sie zu retten:

partial class MyDataContext { 
    public override void SubmitChanges(ConflictMode failureMode) { 
     var delta = GetChangeSet(); 
     foreach(var record in delta.Inserts.OfType<User>()) { 
      if(Users.Any(x=>x.Name == record.Name) {...throw an exception...} 
     } 
     base.SubmitChanges(failureMode); 
    } 
} 

Answer 2

Wenn Sie doppelte Benutzernamen in Ihrer Datenbank vermeiden wollen, warum nicht einen eindeutigen Index auf diesem Gebiet setzen?

Answer 3

ich es nicht testen, noch nicht, aber ich denke, man kann

http://www.devart.com/linqconnect/docs/ExecuteDynamicMethods.html