Telling EF 6 to Ignore a Private Property

Question

I'm using Entity Framework 6.0.2 to map some simple hand-coded models to an existing database structure. The primary model at the moment is:

public class Occurrence
{
    public int ID { get; set; }
    public Guid LegacyID { get; set; }
    public string Note { get; set; }
    public virtual ICollection<OccurrenceHistory> History { get; set; }
}

(The OccurrenceHistory model isn't really relevant to this, but that part is working fine whereby EF loads up the child records for this model.)

The mapping is simple, and I try to be as explicit as I can be (since as the application grows there will be some less-intuitive mapping):

public class OccurrenceMap : EntityTypeConfiguration<Occurrence>
{
    public OccurrenceMap()
    {
        ToTable("Occurrence");
        HasKey(o => o.ID);
        Property(o => o.ID).IsRequired().HasColumnName("ID");
        Property(o => o.LegacyID).IsRequired().HasColumnName("LegacyID");
        Property(o => o.Note).IsUnicode().IsOptional().HasColumnName("Note");
    }
}

But if I add a private property to the model, EF tries to map it to the database. Something like this:

private OccurrenceHistory CurrentHistory { get; set; }

(Internal to the model I would have some logic for maintaining that field, for other private operations.) When EF generates a SELECT statement it ends up looking for a column called CurrentHistory_ID which of course doesn't exist.

I can make the property public and set the mapping to ignore it:

Ignore(o => o.CurrentHistory);

But I don't want the property to be public. The model is going to internally track some information which the application code shouldn't see.

Is there a way to tell EF to just ignore any and all private members? Even if it's on a per-map basis? I'd particularly like to do this without having to add EF data annotations to the models themselves, since that would not only be a bit of a leaky abstraction (persistence-ignorant models would then have persistence information on them) but it would also mean that the domain core assembly which holds the models would carry a reference to EntityFramework.dll everywhere it goes, which isn't ideal.

Answer 1

A colleague pointed me to a blog post that led to a very practical approach.

So what I have is a private property:

private OccurrenceHistory CurrentHistory { get; set; }

The core of the problem is that I can't use that in my mapping:

Ignore(o => o.CurrentHistory);

Because, clearly, the property is private and can't be accessed in this context. What the blog post suggests is exposing a public static expression which references the private property:

private OccurrenceHistory CurrentHistory { get; set; }
public static readonly Expression<Func<Occurrence, OccurrenceHistory>> CurrentHistoryExpression = o => o.CurrentHistory;

I can then reference that in the mapping:

Ignore(Occurrence.CurrentHistoryExpression);

As with anything, it's a mix of pros and cons. But in this case I think the pros far outweigh the cons.

Pros:

• The domain core assembly doesn't need to carry a reference to EntityFramework.dll.
• The persistence mapping is entirely encapsulated within the DAL assembly.

Cons:

• Models need to expose a little information about their inner workings.

The con breaks encapsulation, but only slightly. Consuming code still can't access that property or its value on instances, it can only see that the property exists statically. Which, really, isn't a big deal, since developers can see it anyway. I feel that the spirit of encapsulation is still preserved on any given instance of the model.