2012-04-12 17 views
8

Ich habe die folgende POCO-Klasse erstellt und auch Contact.FirstName und Contact.LastName Eigenschaften privat gemacht (diese Eigenschaften werden entsprechenden Eigenschaften in einem Entity Framework-Modell zugeordnet).Entity-Framework, POCO und eine private Eigenschaft

public class Contact 
{ 
    public int ContactID { get; set; } 
    private string FirstName { get; set; } 
    public string LastName { get; private set; } 
} 

Ich erwartete eine Ausnahme aufgrund EF nicht in der Lage zu bekommen, wobei Werte dieser beiden Eigenschaften zuweisen, aber irgendwie EF verwaltet immer noch Werte ihnen zuweisen. Wie ist das möglich, da nur Code in Contact Klasse Zugriff auf private Eigenschaften haben sollte?

Danke

+31

Entity Framework Magie. Es kann tun, was es will. –

+0

Haben Sie einen Mapping-Code? Das Mappen privater Eigenschaften ohne explizite Konfiguration (oder Anmerkungen in EF 4.3) sollte eigentlich nicht so einfach funktionieren: http://blog.oneunicorn.com/2012/03/26/code-first-data-annotations-on-no-public- Eigenschaften/ – Slauma

+0

@Slauma: Ich benutze Datenbank ersten Ansatz – user702769

Antwort

16

In Umgebungen mit einem ausreichenden Maß an Vertrauen kann reflection Mitglieder verwendet werden, um den Zugriff auf die man normalerweise keinen Zugang hat.

+0

So ist dies auch, wie Test-Projekte Zugang zu privaten Mitgliedern erhalten können? – McGarnagle

+2

@dbaseman: Ja, aber es gibt auch ein 'InternalsVisibleAttribute', das manchmal von Code im Test verwendet wird, um seine' internen' Member für Komponententests zugänglich zu machen, ohne dass überhaupt eine Reflektion benötigt wird. –

+0

Vielen Dank für Ihre Hilfe – user702769

0

Ja - EF, Code zuerst verwenden das in einigen Orten.

ich ein ähnliches Verhalten haben mit privaten Konstrukteurs gesehen - EF/CF können Ihre Objekte konstruieren noch, auch wenn Sie ‚verstecken‘ es oder versuchen (das war das Verhalten in früheren Versionen, jetzt nicht sicher) an :) .

Und ich erinnere mich, einige Diskussionen mit CF-Leuten darüber, warum sie komplexe Eigenschaften nicht initialisieren - vs sie sind immer noch ok mit dem Zugriff auf private Mitglieder (wenn ich mich recht erinnere), war vor langer Zeit.

Also, ein bisschen allgemeine Frage - aber in diesem Sinne hoffe, dass dies zumindest etwas verdeutlicht.

1

Der Vollständigkeit halber: EF5-Code weist zuerst (zumindest standardmäßig) keine privaten Eigenschaften einer Datenbanktabellenspalte zu.

Die folgende Klasse:

public class Person { 
    public int PersonId { get; set; } 
    private string Name { get; set; } 
} 

Mit folgendem DbContext:

public class PrivatePropertiesContext : DbContext { 
    public DbSet<Person> People { 
    get; 
    set; 
    } 
} 

Erzeugt eine Tabelle Personen mit nur einer Spalte: dbo.People.PersonId (PK, int, not null)

Ein öffentlicher Schlüssel Eigenschaft von Standard-Code erforderlich ist erste Konventionen. Wenn die PersonId Eigenschaft in der Klasse Person privat sein würde oder geschützt, wirft Entity Framework die folgende Ausnahme:

System.Data.Entity.Edm.EdmEntityType: : EntityType 'Person' has no key defined. Define the key for this EntityType. 
System.Data.Entity.Edm.EdmEntitySet: EntityType: EntitySet 'People' is based on type 'Person' that has no keys defined. 
Verwandte Themen