Warum wird "Fixup" für persistente Ignorante POCOs in EF 4 benötigt?

Question

Eines der mit Spannung erwarteten Features von Entity Framework 4 ist die Fähigkeit, POCO (Plain Old CLR-Objekte) in einer Ignoranz-Persistenz-Weise zu verwenden (dh sie "wissen" nicht, dass sie mit Entity Framework im Gegensatz zu anderen bestehen) anderer Mechanismus).

Ich versuche, meinen Kopf einzuwickeln, warum es notwendig ist, Assoziationskorrekturen durchzuführen und FixupCollection in meinem "normalen" Geschäftsobjekt zu verwenden. Diese Anforderung scheint zu implizieren, dass das Geschäftsobjekt den Persistenzmechanismus nicht völlig ignorieren kann (tatsächlich klingt das Wort "fixup" so, als müsste etwas repariert/geändert werden, um mit dem gewählten Persistenzmechanismus zu arbeiten).

ich mich beziehen Insbesondere die Vereinigung Fixup Region, die von dem ADO.NET Entity POCO Generator, z.B .:

#region Association Fixup 

    private void FixupImportFile(ImportFile previousValue) 
    { 
     if (previousValue != null && previousValue.Participants.Contains(this)) 
     { 
      previousValue.Participants.Remove(this); 
     } 

     if (ImportFile != null) 
     { 
      if (!ImportFile.Participants.Contains(this)) 
      { 
       ImportFile.Participants.Add(this); 
      } 
      if (ImportFileId != ImportFile.Id) 
      { 
       ImportFileId = ImportFile.Id; 
      } 
     } 
    } 

    #endregion 

sowie die Verwendung von FixupCollection erzeugt wird. Andere gebräuchliche Persistenz-ignorante ORMs haben keine ähnlichen Beschränkungen.

Liegt das an grundlegenden Designentscheidungen in EF? Gibt es ein gewisses Maß an Nicht-Ignoranz hier, um auch in späteren Versionen von EF zu bleiben? Gibt es eine clevere Möglichkeit, diese Persistenzabhängigkeit vom POCO-Entwickler zu verbergen?

Wie funktioniert das in der Praxis, Ende-zu-Ende? Zum Beispiel verstehe ich, dass Unterstützung erst kürzlich für ObservableCollection hinzugefügt wurde (was für Silverlight und WPF benötigt wird). Gibt es in anderen Softwareschichten Probleme mit den Designanforderungen von EF-kompatiblen POCO-Objekten?

Answer 1

Ein paar Erklärungen gefunden - sieh sie dir an!

POCO Template Code Generation Options (EF Team-Blog)

Fixup

Eine Fixup Methode für jede Navigationseigenschaft auf einer Einheit geschrieben und aus dem Setter der Navigationseigenschaft, wenn ihr Wert genannt wird Änderungen. Sein Zweck ist sicherzustellen, dass jedes Ende einer bidirektionalen Beziehung mit der anderen synchronisiert bleibt. Zum Beispiel in einer Eins-zu-viele Beziehung zwischen Cutomer und Ordnung, wann immer Order.Customer gesetzt, der Fixup-Methode stellt sicher, dass die Ordnung in der Sammlung Bestellungen des Kunden ist. Es behält auch die entsprechende Fremdschlüsseleigenschaft dh. Order.CustomerID synchron mit dem neuen Primärschlüssel (ID) des Kunden. Diese Logik kann nützlich sein, wenn die POCO Entities unabhängig vom EF-Stack verwendet werden, wie zum Schreiben von Tests gegen diese, die die Datenbank nicht treffen. Fixup stellt sicher, dass der Objektgraph in der gleichen Weise verbunden ist, wie Sie erwarten würden, während Sie sie mit EF verwenden. Fixup-Methoden sind ein wenig komplex zu schreiben und daher ist es nützlich, sie automatisch erstellt haben, wenn Sie planen, die Entitäten in einem EF unabhängigen Szenario zu verwenden.

Und überprüfen Sie auch diese POCO in the Entity Framework Part 1, die auch einige Abschnitte enthält, welche Korrekturen und was sie benötigt werden.