Guidelines for immutable/readonly entity types

[roji]

We sometimes get questions about immutable entity types. While these aren't really supported (at least not fully), it may be useful to add a page to our modelling section with some info:

• Explanation that regular change tracking isn't possible and why
• Show possible patterns for working around the above with manual change tracking etc.
• Discuss C# 9 init-only properties (Does EF Core 5.0 migration and JSON deserialization work with C#9.0 init-only setters? docs#21741) and records

[joelmdev]

Hopefully this is an acceptable place to ask questions around this as it may help guide the documentation and examples. I know this is discussed to some degree in #21741, but to be explicit, are init-only navigation properties supported in the latest release? At the time of this writing, that would be 5.0.5, I believe. For example:

    public class Article
    {
        private int Id { get; }

        public string Title { get; set; }

        public string Body { get; set; }

        public User Author { get; init; }


        public Article() { }

        public Article(User author)
        {
            Author = author;
        }
    }

Is EF able to both materialize Author and track its changes? If so (or partially), what are the caveats?

[roji]

@joelmdev init-only properties should work fine; they are enforced by the compiler, while EF injects values at runtime via reflection. So you can certainly materialize Article, but then you wouldn't be able to modify Author or save any changes to it.

[joelmdev]

I would expect the reference to Author to be immutable when using an init-only property, but are you saying that changes to the properties of Author are not tracked? For example, assuming Article and Author have already been persisted to and subsequently rehydrated from the db, and article.Author.FirstName == "Bob" is our initial state:

article.Author.FirstName == "Robert";
ctx.SaveChanges();

When the article in question is next rehydrated, The Author's first name would still be "Bob". Is that correct?

[roji]

Yeah, I was a bit ambiguous - you would not be able to change an Article's Author, but you would of course be able to change properties of that Author. The init applies only to the property itself (the reference from Article to Author). So if you change an Author's FirstName to Robert and then save, that change would be persisted and the next time you load that author it will be Robert.

[joelmdev]

Ok, excellent. That's all exactly how I would expect things to work. So it sounds like init-only properties are fully supported. Is that a correct assertion?

If so, do the caveats or partial support mentioned in your original post apply only to records? I read somewhere that they could cause some issues with EF when creating new records using with expressions (I tracked down that "somewhere" while writing this- it was on reddit, the reddit post linked to a youtube video, and the youtube video was bookmarked to you explaining the problem with using records with EF :D https://www.reddit.com/r/dotnet/comments/jt591p/ef_core_with_records/ )

[roji]

So it sounds like init-only properties are fully supported. Is that a correct assertion?

Yes, in the sense that they don't change EF's behavior in any way.

And yes, records are problematic because of their value semantics and usually also because of their immutability. For example, EF doesn't currently have a good story for change-tracking immutable types - "modifying" a record with with (or any immutable type really) means creating a modified copy, which EF has no idea about it and which is difficult to persist back to the database.