EntityFramework und ReadOnlyCollection

9

Ich benutze EntityFramewotk und code first approach. Also beschreibe ich mein Modell so:

%Vor%

Aber meine Domain-Logik erlaubt es nicht, die Eltern-Sammlung zu ändern (hinzufügen, löschen), sie muss nur gelesen werden (nur zum Beispiel). EntityFramework benötigt alle Collections mit ICollection<T> interface und es gibt Add Methode (um Ergebnisse zu materialisieren) und Remove Methode und andere. Ich kann meine eigene Sammlung mit expliziter Implementierung der Schnittstelle erstellen:

%Vor%

Dies blendet Add und Remove Methoden aus, schützt aber überhaupt nicht. Weil ich immer ICollection und verbotene Methoden aufrufen kann.

Also, meine Frage ist:

  • Gibt es eine Möglichkeit, mit schreibgeschützten Sammlungen in EntityFramework zu arbeiten?
Backs 16.08.2015, 04:52
quelle

3 Antworten

1

Kurze Antwort: nein . Und es wäre merkwürdig, dass Sie das können ( na ja, NHibernate kann private Klassenfelder setzen und das bedeutet, dass Sie es mit einer öffentlichen Eigenschaft bereitstellen können, die das Feld als schreibgeschützte Sammlung kapselt ... nun, Sie können dies umgehen Situation in EF auch: Entity Framework Viele zu viele durch containing Objekt Übrigens, ich würde Ihnen diesen Ansatz nicht empfehlen, denn Wie können Sie neue Eltern hinzufügen, wenn es sich um eine private Eigenschaft handelt? )

Wie auch immer, ich glaube, dass ein Domain-Objekt read-write sein sollte, denn am Ende des Tages beschreibt ein Domain-Objekt eine Entity innerhalb der Domain und Sie sollten darauf zugreifen und sie modifizieren können.

Eine alternative Lösung besteht darin, ein Interface so zu gestalten, dass Parents als IReadOnlyList<Person> und auch IPerson mit allen Person -Mitgliedern außer Parents verfügbar ist und Person als IPerson zurückgibt:

%Vor%

Und implementieren Sie IPerson implizit auf Person excepting Parents , das explizit implementiert werden würde . Wenn Sie irgendwo Person zurückgeben müssen, geben Sie IPerson statt Person zurück:

%Vor%

Sie können argumentieren, dass Sie möglicherweise IPerson auf Person reduzieren können, aber an dieser Stelle würde ich Ihnen sagen, dass Sie Ihren eigenen Kodierungskonventionen folgen müssen: Wenn Sie definiert haben, dass Sie niemals Person zurückgeben aber IPerson , dann würde ich es auf diese Weise in der gesamten Codebasis tun, und wenn Sie eine schreibfähige Parents -Eigenschaft benötigen, dann geben Sie stattdessen Person zurück (und vermeiden später eine Umwandlung!).

    
Matías Fidemraizer 16.08.2015, 06:46
quelle
5

Sie können private Auflistungseigenschaften für EF verfügbar machen, sodass Sie Mapping und Abfragen durchführen können, während die Member und Beziehungen Ihres Domänenobjekts weiterhin ordnungsgemäß gekapselt bleiben. Es ist ein bisschen chaotisch, aber es funktioniert:

%Vor%

Mapping verwendet dann:

%Vor%

Dieser Ansatz wird hier weiter beschrieben: Ссылка

    
ssmith 07.06.2016 19:33
quelle
1

Nun, es gibt einen Weg. Es ist nicht schön, weil es zusätzliche Sachen in Ihrem Domain-Modell hinzufügt, aber ich habe es einfach überprüft und es funktioniert.

Alle Credits gehen an Owen Craig.

Ссылка

Beispiel in einer Nussschale

Stellen Sie sich vor, wir haben ein bestehendes Modell mit Organisation = & gt; Mitarbeiter bereits eingerichtet.

Um diese Technik anzuwenden, müssen wir das Organisationsmodell ein wenig ändern:

%Vor%

Ändern Sie die fließende Konfiguration in Ihrem Datenbankkontext:

%Vor%

Ändern Sie alle Include-Anweisungen, falls Sie LazyLoading nicht verwenden

%Vor%

Glückliches DDD!

    
Kaspars Ozols 22.04.2016 07:42
quelle

Tags und Links