Always write to and read from backing fields by default

[ajcvickers]

However, also consider notification entities where setting the property may be needed to trigger the notification.

[sjb-sjb]

The advantage to backing fields cited in https://docs.microsoft.com/en-us/ef/core/modeling/backing-field is that one can then have private property setters.

The programmer's decision to have property setters used for materialization (or, for example, for reversion when State is set to Unchanged) is likely based on very different considerations than the decision of whether a given property should be public or private. Therefore, it would be very useful to be able to have EF use the property setter even though it is private. This would not be a breaking change.

[ajcvickers]

@sjb-sjb EF Core has always been able to map private (protected, internal, etc.) properties. I'm curious what the text is in that link that made you think otherwise.

[sjb-sjb]

It maps the property, but does it write to it using a private property setter? I think it uses the backing field instead, if the setter is private (or, equally, internal). Maybe I'm wrong on this point? I want the setter to be private or internal but I want it to be used by EF. This is because I view EF as part of the "internal" implementation of my package. I want to allow more access for EF to do it's thing than I want to give to the end consumers of my classes.

[ajcvickers]

@sjb-sjb EF maps to, writes to, and reads from private getters and setters, as well as fields, depending on our the property is configured.

[sjb-sjb]

Ah ha! Great!

[sjb-sjb]

@ajcvickers responding to your question "I'm curious what the text is in that link that made you think otherwise", I was taken in by the sentence that says "If the property is read-only, then it will write to the field."

I read this a bit too quickly perhaps and I thought that 'read-only' referred to the perspective from outside the class, i.e. public getter, private setter would mean read-only. I suppose it meant no setter at all.

[ajcvickers]

@sjb-sjb Thanks for the feedback.

[ajcvickers]

Re-opening to ensure breaking change is announced.

[vanillajonathan]

With this you will be able to expose a navigational property as a IReadOnlyCollection.

Example:

public class Blog
{
    private List<Post> _posts = new List<Post>();

    public int BlogId { get; set; }
    public string Url { get; set; }

    public IReadOnlyCollection<Post> Posts => _posts.AsReadOnly();
}

[ajcvickers]

@vanillajonathan That is already possible. This change means that it should work without additional configuration to tell EF to map to the field.

[ajcvickers]

@sjb-sjb But it's not read-only...

[bigworld12]

how does this stack with #2968 ? if you force all read/writes to fields, how are you going to implement custom getters/setters for properties ?

[sjb-sjb]

@bigworld12, for my purposes the point is that EF will use direct field access during materialization while my application code will use the setters/getters. I want different things to happen in the two cases.