Working with backing fields independent of property type

[glucaci]

Currently is not possible to have a different type on the backing field than on the Property.
My ideea was that EF works only with the backing field independent of the property type and use the property name to "fetch" the Column.

Given the next model:

public class Customer
{
   private string _name;

   protected Customer() { }

   public Customer(string name)
   {
      _name = name;
   }

   public CustomName Name => (CustomName)_name;
}

public class CustomName : ValueObject<CustomName>
{
    public CustomName(string value)
    {
        Value = value;
    }

    public string Value { get; }

    public static explicit operator CustomName(string value)
    {
        return new CustomName(value);
    }

    public static implicit operator string(CustomName customName)
    {
        return customName.Value;
    }
}

I can achieve this with a weird workaround by creating a shadow property with different name than the model property

var propertyName = nameof(Customer.Name);
modelBuilder
    .Entity<Customer>()
    .Property<string>($"_{propertyName}")
    .HasColumnName(propertyName)
    .HasField($"_{propertyName.ToLowerInvariant()}");

It's planed to do it in another way or can be done currently in a simpler way?
Thanks

[ajcvickers]

@glucaci You can map the field directly and not map the property at all:

modelBuilder.Entity<Customer>(b =>
{
    b.Ignore(e => e.Name);
    b.Property("_name");
});

But then you will not be able to use the property directly in a query since EF doesn't know how to handle the "CustomName" class.

Beyond that, when #242 is implemented, you can configure the property with a value converter to allow CustomName to be converted to a string when reading and writing to the database.

[ajcvickers]

@glucaci After discussing in triage we have a follow-up question: what is the reason for including the backing field specifically as a string? Was this just an attempt to get things working with EF, or is there some other reason it is there?

[glucaci]

No other reason @ajcvickers. Only trying to map the model to the DB and in the same time keep the API clean.

This with converters sounds nice, there will be some limitations? For example looking on the "CustomName" type or something else that contains composed ValueObjects?

[ajcvickers]

@glucaci Thanks for the additional info. I'm going to close this as a duplicate of #9906. There needs to be some more design to understand what this will actually involve, but this issue is valuable input into that process.