Improve backing field modeling page #2005
Conversation
roji
commented
Dec 20, 2019
roji
commented
- Reorganize content based on topics and not convention/fluent API/data annotations, as done in Merge relational database modeling into general modeling #1669.
- Correct the documentation of the default property access mode (change from PreferFieldDuringConstruction to PreferField in 3.0), and add a note on the behavior change.
- Various other cleanups and improvements.
* Reorganize content based on topics and not convention/fluent API/data annotations, as done in #1669. * Correct the documentation of the default property access mode (change from PreferFieldDuringConstruction to PreferField in 3.0), and add a note on the behavior change. * Various other cleanups and improvements.
|
|
||
| [!code-csharp[Main](../../../samples/core/Modeling/FluentAPI/BackingField.cs#Sample)] | ||
| By default, EF will always read and write to the backing field - assuming one has been properly configured - and will never use the property. However, EF also supports other access patterns. For example, the following sample instructs EF to write to the backing field only while materializing, and to use the property in all other cases: |
There was a problem hiding this comment.
I think this is misleading. By default, EF will always read and write to the backing field so long as the backing field has been discovered or configured as described above. The property will be used if the backing field is not known.
There was a problem hiding this comment.
Do you think that "assuming one has been properly configured" isn't sufficient here? Maybe "assuming one has been properly discovered or configured", or something else?
|
|
||
| You can also create a conceptual property in your model that does not have a corresponding CLR property in the entity class, but instead uses a field to store the data in the entity. This is different from [Shadow Properties](shadow-properties.md), where the data is stored in the change tracker. This would typically be used if the entity class uses methods to get/set values. |
There was a problem hiding this comment.
I would not necessarily call this the "typical" case, even though it is a common case. Another common case is for fields that should not be exposed at all in the domain model, such as primary keys.
There was a problem hiding this comment.
Pushed a change, let me know what you think.
