IMO it would also make sense to document how simple expression bodied db-sets are an alternative way to define DbSet properties.

So instead of using mutable auto properties like this:

public class NullableReferenceTypesContext : DbContext
{
    public DbSet<Customer> Customers { get; set; } = null!;
    public DbSet<Order> Orders { get; set; } = null!;
}

Using expression bodied get-only properties can be a more natural way to define them.

public class NullableReferenceTypesContext : DbContext
{
    public DbSet<Customer> Customers => Set<Customer>();
    public DbSet<Order> Orders => Set<Order>();
}

Pros:

Immutable DBSet properties. It makes no sense to have mutable db-sets. So why even declare them mutable if they are not.
"Natural" fix for CS8618 because Set<>() has a none-nullable return value.
No property initialization cost because when constructing a new context EF does not have to initialize all DbSet properties in advance. (Although this is highly optimized anyway, so no real measurable benefit).

Note that I am not arguing against the suppressor. I am just wondering why the auto-properties "way" of defining DBSets, is still the default one described in all the docs etc? Probably just because of historical reasons? Does it make sense to re-evaluate this default? Thoughts @ajcvickers @roji ?

Write a DiagnosticSuppressor for CS8618 for DbSet properties #21608

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions