Custom property access patterns

[divega]

Currently EF uses some hardcoded assumptions involving properties and fields to:

1. Decide whether a property with a specific name and type exist on an entity
2. Get the property's value for change tracking and persistence purposes
3. Set the property's value during materialization or fixup

The article at http://www.codeproject.com/Articles/399932/Extension-Properties-Revised describes an example a non-standard property access pattern that EF could support in the future.

Another much more well-known pattern I expect many customers to want to use is to store property values into an property bag (e.g. IDictionary<string, object>) in the entity itself.

It seems to me that the first step to support patterns like those would be to refactor the current assumptions into a default property access pattern and to allow for alternative property access patterns to be registered with EF. I.e. you would need to be able to tell EF that for a specific property you want it to use specific expressions for getting and setting the value, e.g. the default property access pattern using an actual property could be expressed somewhat like this (I have taken some shortcuts: made up a couple of method names and assumed no field access):

modelBuilder.Entity<Product>().Property<DateTime>("Expiration")
    .Getter(p => p.Expiration)
    .Setter((p, value) => p.Expiration = value);

To register an "extension property" as described in the article linked at the beginning, you would need to write something like this:

modelBuilder.Entity<Product>().Property<DateTime>("Expiration")
    .Getter(p => p.GetValue<DateTime>("Expiration"))
    .Setter((p, value) => p.SetValue("Expiration", value));

For an property bag you would write something like this:

modelBuilder.Entity<Product>().Property<DateTime>("Expiration")
    .Getter(p => (DateTime)p.ExtendedProperties["Expiration"])
    .Setter((p, value) => p.ExtendedProperties["Expiration"] = value);

Then the next step would be to make all of this more usable by figuring out a way to write it in a more generic way, so that end uses wouldn't need to repeat themselves. E.g. for illustration, let's say that property access patterns could be represented by a class (which probably implements some interface), then a user could write something like this:

modelBuilder.Entity<Product>().Property<DateTime>("Expiration").AccessAs<ExtensionProperty>();

Custom property access patterns like this could generate expressions with additional logic, e.g. to throw a nicer exception if a value of an invalid type is encountered, to take advantage of fields, etc.

Discovery I would expect that in most cases the motivation to use a pattern like this has to do with needing an entity that is more loosely typed (see support for dynamic models at https://github.com/aspnet/EntityFramework/issues/2282). For those cases the entity by design does not contain reflection information about the property and hence the property has to be explicitly declared in the model.

Yet, it is possible that in certain scenarios the entity type could contain information about the property, but encoded in a different way from what a standard property would look like to reflection. These scenarios could be handled by allowing customizing property discovery logic.

[divega]

For triage: obviously this is intended for the backlog.

[natemcmaster]

Another scenario to consider: materializing a property that depends on another property.

Example: when materializing ColumnModel from sys.columns, the column max_length comes back in terms of bytes. For unicode char columns, this means the getter for MaxLength needs to be able to access other properties while determining how to set the appropriate value.

modelBuilder.Entity<ColumnModel>().Property(c => c.MaxLength)
    .Getter(p => p.MaxLength)
    .Setter((p, value) => {
        p.MaxLength = 2;
        if (p.DataType == "nvarchar") // <--- access a different property on the object while setting
        {
            p.MaxLength /= 2;
        }
    });

[AndriySvyryd]

This will likely imply making PropertyAccessors or similar abstraction part of IPropertyBase and making PropertyInfo, FieldInfo, IsShadowProperty, IsIndexedProperty members of PropertyAccessors or extension methods.