dotnet
Make more clear that parameterless constructors have priority
From the page:
When EF Core creates instances of these types, such as for the results of a query, it will first call the default parameterless constructor and then set each property to the value from the database. However, if EF Core finds a parameterized constructor with parameter names and types that match those of mapped properties, then it will instead call the parameterized constructor with values for those properties and will not set each property explicitly.
This suggests that parameterized constructors have priority over default parameterless in the case where both exist. My understanding from the comments on #10789 is the opposite:
@xKloc Starting with preview2, if there are both parameterized and empty constructors, then EF will choose the empty one. See #10852
Originally posted by @ajcvickers in https://github.com/dotnet/efcore/issues/10789#issuecomment-379503174
I suggest the document wording be revised to make it clearer. It has taken me some digging today to clarify it.
My domain model has parameterised constructors that trigger domain events, so it is important EF uses the protected parameterless ones.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
- ID: ecc7aedf-6301-7ec7-4f65-81749b1f54c8
- Version Independent ID: d0774ffa-c841-e6df-72de-d7f53c0d6f6f
- Content: Entity types with constructors - EF Core
- Content Source: entity-framework/core/modeling/constructors.md
- Product: entity-framework
- Technology: entity-framework-core
- GitHub Login: @ajcvickers
- Microsoft Alias: avickers
Guys, 4 years from this. Common, is it so difficult to edit doc?
How to prioritize constructor for EF Core? I need some initialization logic in constructor and want it to be clear for users which one is for public and which is for EF Core
I tried something like this, but EF Core always choose constuctor with lower amount of parameters. But from doc it should use the 1st one.
Afterwards, we with team created really dirty hack to bypass this behaviour. We just renamed payload to body, to force EF Core not to use constructor for package consumers