Provide a data annotation for setting backing fields

[ajcvickers]

This would allow a property to be annotated with a backing field directly in the class. One advantage of this is that the nameof() syntax could be used to reference the field.

[lajones]

@ajcvickers Let me know what you think of this design for the new attribute (I was thinking of putting it in EFCore.Abstractions next to OwnedAttribute:

namespace Microsoft.EntityFrameworkCore
{
    /// <summary>
    ///     Names the backing field associated with this property.
    /// </summary>
    [AttributeUsage(AttributeTargets.Property)]
    public sealed class BackingFieldAttribute : Attribute
    {
        /// <summary>
        ///     Initializes a new instance of the <see cref="BackingFieldAttribute" /> class.
        /// </summary>
        /// <param name="name">The name of the backing field.</param>
        public BackingFieldAttribute([NotNull] string name)
        {
            Check.NotEmpty(name, nameof(name));

            Name = name;
        }

        /// <summary>
        ///     The name of the backing field.
        /// </summary>
        public string Name { get; }
    }
}

[ajcvickers]

@dotnet/efcore Do people think this should be its own annotation? Or should we have one attribute for property mapping and facets? Or one attribute for property mapping, one for facets?

[smitpatel]

What is property mapping? And which facets are we planning to add annotations for?

[ajcvickers]

Maybe we should make a list of all the things that can be configured for with the fluent API for which there are no attributes?

[lajones]

Not sure this is exhaustive, but a quick look at the docs shows the following Fluent API with no attribute equivalent (note: some of these don't apply to properties and so may not be relevant here):

• configuring composite keys
• name of PK/FK constraints
• HasPrincipalKey()
• HasAlternateKey()
• cascade delete
• HasIndex() (and its name and included properties)
• HasDiscriminator()
• HasSequence()
• HasField() and UsePropertyAccessMode()
• value conversions
• data seeding
• HasNoKey()

[lajones]

Notes from team discussion 2/19/20:
In general we prefer small individual attributes over attributes which represent a combination of facets, e.g. we'd prefer Unicode and Precision as separate attributes, but we may make exceptions where concepts are closely tied together, e.g. Precision and Scale might well end up together.

For this particular issue we decided (at least for now) to use one attribute for BackingField which embodies just the name of the backing field and decided not to include the concept of PropertyAccessMode on the same one as that could also be applied to classes.