How do you use shadow properties in EF Core?

Related To: Data Modeling, Entity Properties, Change Tracking, Database Mapping, Auditing, Inheritance

What are Shadow Properties in EF Core?

Shadow properties in EF Core are properties that are part of your entity’s model and mapped to database columns, but they do not have a corresponding property defined in your C# entity class. Essentially, EF Core manages these properties internally without them being exposed directly on your C# objects.

They are particularly useful for storing data that is primarily relevant to the database or EF Core’s internal mechanisms, such as computed values, discriminator columns for Table-Per-Hierarchy (TPH) inheritance, or auditing information like CreatedAt or LastUpdated timestamps.

How to Define Shadow Properties

Shadow properties are configured within your DbContext class, specifically by overriding the OnModelCreating method. This is where you define your entity mappings and relationships.

1. Use the Property<TValue> Method

Within OnModelCreating, you use the Property<TValue> method on your entity configuration to tell EF Core about the shadow property’s existence, its name, and its data type.

// In your DbContext class...
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    // Define a shadow property called "LastUpdated" of type DateTime for the BlogPost entity
    modelBuilder.Entity<BlogPost>()
        .Property<DateTime>("LastUpdated");

    // You can also configure other aspects, like making it required or setting a default value
    modelBuilder.Entity<Product>()
        .Property<string>("Discriminator")
        .IsRequired();
}
    

How to Access Shadow Properties

Since shadow properties do not exist as direct C# properties on your entity objects, you cannot access them using standard dot notation (e.g., product.LastUpdated). Instead, you interact with them through EF Core’s ChangeTracker API.

1. Access via ChangeTracker

The ChangeTracker allows you to inspect and modify entity properties, including shadow properties, for entities being tracked by the DbContext.

// Somewhere else in your code, typically in a service or repository
using (var context = new MyDbContext())
{
    // Get the entity you want to update (it must be tracked by the context)
    var blogPost = context.BlogPosts.Find(1); 

    if (blogPost != null)
    {
        // Set the value of the shadow property
        context.Entry(blogPost).Property("LastUpdated").CurrentValue = DateTime.UtcNow;

        // Retrieve the value of a shadow property (e.g., for logging)
        var lastUpdatedValue = context.Entry(blogPost).Property("LastUpdated").CurrentValue;
        Console.WriteLine($"Blog Post ID 1 Last Updated: {lastUpdatedValue}");

        context.SaveChanges(); // Save changes, including the updated shadow property
    }
}
    

Common Use Cases for Shadow Properties

Shadow properties shine in scenarios where data is important for the database or EF Core’s ORM capabilities, but less so for the immediate C# application logic.

• Auditing Information: Automatically tracking CreatedAt, LastUpdatedAt, CreatedBy, or LastUpdatedBy timestamps/user IDs without cluttering every entity class with these properties.
• Discriminator Columns: Essential for implementing Table-Per-Hierarchy (TPH) inheritance, where a column is needed to distinguish between different types of entities stored in the same table. This keeps your C# base class clean.
• Computed Values: Storing values that are derived or computed by the database (e.g., a full name concatenated from first and last names) that you don’t need to manipulate directly in C#.
• Internal EF Core Mechanisms: Sometimes used internally by EF Core for various features, like tracking certain relationships or conventions.

Key Characteristics and Benefits

• Clean Entity Classes: Prevents your C# entity classes from being cluttered with properties that are purely for database concerns or internal EF Core mechanisms.
• Database Mapping: Shadow properties are fully integrated into EF Core’s model and are mapped to columns in your database schema, just like regular properties.
• Change Tracking: EF Core treats shadow properties just like regular properties when it comes to change tracking. Any modification to a shadow property’s value will be detected and reflected in the database upon SaveChanges().
• Queryable: You can use shadow properties in LINQ queries, just like regular properties. For example, context.BlogPosts.OrderByDescending(b => EF.Property<DateTime>(b, "LastUpdated")).

Considerations and Trade-offs

While powerful, shadow properties come with certain trade-offs:

• Less Transparency: Because they don’t appear directly in your C# entity classes, new developers might find the code less intuitive or discoverable. You need to explicitly know about their existence and access them via the ChangeTracker or EF.Property.
• Indirect Access: Accessing values requires using the ChangeTracker or EF.Property method, which adds a slight layer of indirection compared to direct property access.

It’s important to weigh the benefit of cleaner entity classes against the slight increase in complexity when accessing these properties. For common database-level concerns like auditing or inheritance discriminators, the improved code clarity in entity classes often outweighs the slightly less direct property access.

Interview Insights on Shadow Properties

When discussing shadow properties in an interview, consider highlighting practical scenarios and trade-offs:

• Explain the “Why”: Provide a real-world example. “In a recent project, we used shadow properties for a discriminator column in a table-per-hierarchy inheritance setup. We had different user types (e.g., ‘Customer’ and ‘Admin’) inheriting from a base User class. Using a shadow property for the discriminator kept our User C# entity class clean, as the UserType column was purely a database concern. This made our code easier to understand and maintain, as the inheritance logic was handled entirely by EF Core without cluttering our domain model.”
• Discuss Change Tracking: Emphasize how EF Core handles them. “EF Core treats shadow properties just like regular properties when it comes to change tracking. In the user scenario, if a user’s role changed, EF Core automatically detected the change to the discriminator shadow property and updated the database accordingly. This simplifies development because we didn’t have to manually manage the discriminator value.”
• Mention Downsides/Trade-offs: Show a balanced perspective. “While shadow properties are useful, they can sometimes make the code less transparent. Since they’re not directly in the entity class, you have to go through the ChangeTracker or EF.Property to access them. This can be slightly less intuitive for developers unfamiliar with them. However, in situations like the discriminator example, the improved code clarity in the entity classes often outweighs the slight complexity of accessing the property indirectly. It’s a trade-off between clean entity classes and slightly less direct property access.”