Can I use EF Core with immutable object?

[mfilippov]

Can I use EF 7 with immutable object with read-only properties and without parameter less constructor?
As example:

public class User
{
    public User(int id, string name)
    {
        Id = id;
        Name = name;
    }

    public int Id { get; }
    public string Name { get; }
}

[rowanmiller]

This would be enabled by #240 (which we are planning to do)

[antonioortizpola]

3 years and a simple immutable objects can not be used (unless you do some workarounds), this is really sad, considering c# 7 and 8 come with more and more support for functional programming

[divega]

@antonioortizpola I recommend that you create a new issue including details about the code that you would like to write. There have been improvements around this area and some things already work.

[antonioortizpola]

Thanks for the response!, however, I do not see a point in open a new thread, since the code already posted at the beginning is exactly what i would like to do, the closest to this is to add a protected empty constructor and the one with your parameters, but still feel more like a workaround than a solution.
This takes more importance with the addition of Records in C# 8, since could simplify some entity mappings.
Also, with functional programming taking more and more importance, it would be nice to see immutable objects as a considered option.

[ajcvickers]

@antonioortizpola In 2.1 preview1, the code for the entity type above should work fine. However, be aware that if the key is real read-only (as it is above, as opposed to exposing a read-only public API), then store-generated keys will not work since they need to set the key field after reading it from the database.

[divega]

@antonioortizpola it is a process thing: In our triage meeting we review open issues with no milestone assigned. We never discuss comments on closed issues.

Anyway, the other reason I asked you to create a new issue with the code that you would like to write is because I was hoping it would capture your untainted expectation on what to do beyond object mapping: there is more to immutable object support that just writing an immutable class and being able to map it (as @ajcvickers said, this generally will work in 2.1). Specifically, what are your expectations re performing updates on the database. I see two possibilities:

1. You will never perform updates on the database. Only inserts and deletes. I.e. immutability extends to rows in the database.
2. You expect to be able to replace immutable instances with other immutable instances with different data. I believe this only works under very constrained conditions in 2.1.

@ajcvickers do you remember if we already closed-as-fixed some issue based on what you did in 2.1 that enables immutable objects? Otherwise, mind if we use this issue?

[antonioortizpola]

Thanks for the responses. I understand about the process thing, sorry if I sounded rude or putting pressure, i just wanted to know, in general i'm happy with the normal approach and the performance hits are neglectable, however, after learning some functional programming and using immutability, we have been able to improve some particulars parts of our system with concurrent code, reducing our bugs, locks and other things with very elegant code, (we thought use Dapper, but EF is working great).

In that context, our process works with the objects and the ORM works as a simple parser, and we included EF-Plus to handle some updates avoiding load entities, but our "DataProviders" are filling with temporal objects or protected constructors, I did not know that the above code will work from 2.1, sorry about that :S.

Sadly our main system is pre-Core, so we will not have that feature over there, luckily we are working in some new developments with core so we will try that right away. So thanks again for the effort, the attention and the openness, i will be watching #240 and this for updates.

Also, i will check the docs page to add this to the discussion if someone want something similar.

[ajcvickers]

@divega #10703 is the 2.1 issue. However, your points about allowing replacing immutable instances with new instances is very interesting. I think we should leave this issue on the backlog to cover that--could allow store-generated keys too--and leave #10703 to be specifically about the constructor support.

[ajcvickers]

Triage: filed #11457 to cover updates to immutable entities. Closing this as a duplicate of #10703.