custom O-C mapping contributions

Topics: EF Runtime, General
Jan 13, 2013 at 10:09 AM


Undoubtedly, many developers are waiting for new features within "custom O-C mapping".
This work would have many different "user stories", but we could try to start with some simple scenarios to go further extending the work. I think I could help with any of these scenarios, for example with "backing fields mapping" with the idea
of having some things like:

Materialize in backing fields ( properties without set )

     .ToCamelCaseField(); // or ToUndescoreCamelCaseField()

Materialize in fields ( properties in EDM but not in object spaces )

     .ToUndescoreCamelCaseField(); // or ToCamelCaseField()

Would the team interested in any contribution in this regards???

Thanks in advance
Unai Zorrilla



Jan 29, 2013 at 7:49 PM

Hello Unai,

Thank you once more for your continued interest in contributing to EF! As you may have noticed in recent triage notes, we are already at a stage in which we are actively avoiding increasing the scope of the work we take in EF6 and we are focusing instead on finishing in-flight features, fixing bugs, improving performance and making other small polish changes. This focus on landing EF6 also necessarily means that we have to be very cautious with the community contributions we accept in coming months.

With that in mind, a few of us in the team discussed and came up with an idea of an O-C mapping improvement that would require only minimal changes in the codebase and in the public surface but that would still have a significant positive impact on the experience of using EF:

The idea is that we could simply allow using private fields in materialization when the corresponding property setter is not present. At least initially, we would require the property getter to exist and the underlying storage field to match some simple naming rules, e.g. came-case, underscore-camel-case, etc. Allowing this should be enough to simplify the usage of EF in many scenarios in which the developer wants to restrict the interaction of other parts of the application with the data, e.g. to define seemingly immutable types. The approach also leaves room for the introduction of granular configuration options in the future, e.g. we could add new API to specify the name of the field,  to force using fields for materialization even when the setter is available (e.g. to avoid executing extra logic contained in the setter during materialization), etc. In that context, the simple support for materialization to fields described in this proposal would then become just a convention.

There are still open issues with this approach, e.g.:

  1. We need to be careful with the breaking change aspects of it: If we simply enable this new behavior for default, EF Code First will start recognizing properties that used not to be persistable in existing models. If we believe this is going to be an issue in many cases we should consider adding this to the new convention set of EF6, making it optional, etc.
  2. Can this be made to work with EDMX-based models? One idea there is to add the possibility of setting the SetterAccess annotation to “None” and update the DbContext template to be able to generate a read-only property with a backing field in that case.

Please read this an example of something we could potentially include in EF6. Other approaches are possible, but the bigger the change to the API surface or to the code the more chances we will ask you to wait until the next release. Feel free to contact us when you want to discuss more details or if you have a different proposal.

I am also putting together a one-page spec that tries to outlines the full scope of custom O-C mapping. We believe this is a super important area full of huge opportunities. I will post a link here when I publish it.


Jan 30, 2013 at 11:15 AM

Hi Diego,

Thanks for this clarification, I agree with creating a new convention to support "fields materialization", Regarding your questions:

1 - As optional convention might be the best solution...

2- try to see how easy it could be


Thanks again for your support


Mar 15, 2013 at 7:26 PM
Unai, Diego,

Is this something that you guys have made progress on in the past month? The materialization to private fields sounds like a great story to tackle, and I'm interested in contributing.

Apr 10, 2013 at 11:09 AM

Yes, I'm try to finish the pull request this week. Currently I have an issue, but I hope the team can help me with this today :-).... Of course, the team will evaluate it to see if is correct and in good quality.

Apr 15, 2013 at 2:23 PM
Hi Unai,

I took a look at the code as discussed and I am responding here to keep the conversation together and in a place where others can see.

I didn't look at all aspects of the code but focused on the issue you raised concerning related ends and metadata lookup. It seems to me that a better approach might be to put the information needed to do field access into the NavigationProperty instance when it is created. This seems to be the place where o-space metadata for property access is currently stored and so it seems reasonable to extend this to store field information as well. This should avoid the need to access the context/MetaWorkspace at other times.

Hope this helps. If this doesn't work out feel free to ping us again and I'll take another look.

Apr 15, 2013 at 2:59 PM
I took a look and add more commit in pull request if I solve this issue..

thanks again Arthur

Apr 24, 2013 at 8:44 AM
I'm afraid I'm a little late to the party here, but would like to add a use case for materialization directly to backing fields:

I would like to be able to have the property setter to contain some logic/validation. For example a status field setter could validate that when a specific status is set, it is legal to transition from the current state to the new one. Consider e.g. a rule that status "Published" can only be set on items that have status "Approved". During materialization I don't want those validation rules to apply, or it won't be possible to load an item that has status "Published".

As I understand your solution listed above that wouldn't be possible (yet). Is it anything you have considered or looked into?

Best Regards,
Apr 24, 2013 at 8:51 AM
andersabel, yes ,this scenario would work when this feature is finished and approved.

Jul 19, 2013 at 4:57 AM
Edited Jul 19, 2013 at 4:58 AM
I've used NHibernate for years on several projects and not being able to map to a private backing field for both "read-only / calculated" properties and IEnuermable properties with backing field collections is a massive feature gap.

If backing field mappings aren't supported out of the box with EF6 would it still be possible to accomplish this by adding a custom convention?