Custom property access patterns

Start by tracing the hardcoded property discovery, value-getting, value-setting, materialization, and change-tracking assumptions described in the issue, then compare them with the dynamic models discussion in issue #2282. Done would require a settled design for registering custom discovery and access patterns, including getter and setter behavior for extension properties or property bags.

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.