2010-06-13 18 views
6

Ich habe eine ziemlich tiefe Hierarchie von Objekten, die ich mit Entity Framework 4, POCO, PI (Persistenz Ignoranz) und Code First bestehen will. Plötzlich begannen die Dinge ziemlich gut zu funktionieren, als mir klar wurde, dass ich den neuen() Operator nicht verwenden sollte. Wie ursprünglich geschrieben, verwenden die Objekte häufig new(), um untergeordnete Objekte zu erstellen.Entity Framework 4 Code First und der new() -Operator

Stattdessen verwende ich meine Sicht auf das Repository-Muster, um alle untergeordneten Objekte nach Bedarf zu erstellen. Zum Beispiel gegeben:

class Adam 
{ 
    List<Child> children; 
    void AddChildGivenInput(string input) { children.Add(new Child(...)); } 
} 

class Child 
{ 
    List<GrandChild> grandchildren; 
    void AddGrandChildGivenInput(string input) { grandchildren.Add(new GrandChild(...)); } 
} 

class GrandChild 
{ 
} 

("GivenInput" impliziert eine gewisse Verarbeitung hier nicht dargestellt)

Ich definiere ein AdamRepository wie:

class AdamRepository 
{ 
    Adam Add() 
    { 
     return objectContext.Create<Adam>(); 
    } 
    Child AddChildGivenInput(Adam adam, string input) 
    { 
     return adam.children.Add(new Child(...)); 
    } 
    GrandChild AddGrandchildGivenInput(Child child, string input) 
    { 
     return child.grandchildren.Add(new GrandChild(...)); 
    } 
} 

Nun, dies funktioniert gut genug. Allerdings bin ich nicht länger "ignorant" von meinem Beharrlichkeitsmechanismus, da ich den neuen() Operator aufgegeben habe.

Darüber hinaus bin ich ein Risiko von anemic domain model, da so viel Logik im Repository statt in den Domänenobjekten landet.

Nach viel adieu eine Frage:

Oder besser gesagt mehrere Fragen ...

  • Ist das Muster erforderlich mit EF 4 Code Zunächst zu arbeiten?
  • Gibt es eine Möglichkeit, die Verwendung von new() beizubehalten und trotzdem mit EF 4/POCO/Code First zu arbeiten?
  • Gibt es ein anderes Muster, das Logik im Domänenobjekt belassen und trotzdem mit EF 4/POCO/Code First arbeiten würde?
  • Wird diese Einschränkung in späteren Versionen der Code First-Unterstützung aufgehoben?

Manchmal versuchen die POCO/ Persistence Ignorance Weg stromaufwärts schwimmen gehen fühlt sich an wie, andermal wie Schwimmen bis Niagara Falls fühlt. Aber ich mag glauben, ...

Antwort

4

Hier sind ein paar Punkte, die Ihre Frage beantworten helfen können:

die Kinder in Ihren Klassen haben Sie ein Feld für die Kinderkollektion und ein Verfahren hinzufügen . EF im Allgemeinen (nicht nur Code First) erfordert derzeit, dass Auflistungen als Eigenschaften auf der Oberfläche stehen, daher wird dieses Muster derzeit nicht unterstützt. Mehr Flexibilität bei der Interaktion mit Klassen ist eine häufige Frage für EF und unser Team untersucht, wie wir dies im Moment unterstützen können.

Sie erwähnten, dass Sie Entitäten explizit mit dem Kontext registrieren müssen, dies ist nicht unbedingt erforderlich der Fall. Wenn im folgenden Beispiel GetAdam() ein Adam-Objekt zurückgegeben hat, das an den zugrunde liegenden Kontext angefügt ist, wird das neue untergeordnete Cain automatisch von EF erkannt, wenn Sie speichern und in die Datenbank einfügen.

var adam = myAdamRepository.GetAdam();

var cain = new Kind();

adam.Children.Hinzufügen (Kain);

~ Rowan

+0

Willkommen bei Stack Overflow. Das grundlegende Problem ist, dass ich wirklich eine tiefe Objekthierarchie habe, in der jede Ebene Instanzen von Objekten der nächsten Ebene erstellen kann. Nach meinem Verständnis und meiner Erfahrung müsste ich meine Objekthierarchie manuell durchlaufen, um alle Objekte einzeln an einen ObjectContext anzuhängen, bevor sie persistiert werden können. Meine Anwendung ist ziemlich komplex, aber ich werde versuchen, sie zu einem einfachen, vollständigen Beispiel zu destillieren. Wird heute aber nicht passieren, hoffentlich morgen. –

+1

@Eric J, das ist nicht, was ich von Rowans Antwort verstanden habe. Für mich klingt es wie "Wenn Sie etwas zur öffentlichen Sammlung verwandter Objekte hinzufügen, speichert EF diese Entität automatisch, auch wenn Sie sie nicht explizit zum ObjectContext hinzugefügt haben". Dies entspricht dem Verhalten von LINQ to SQL. –

Verwandte Themen