This is - in my opinion - the most important feature EF has added in years (even more so than `ExecuteUpdateAsync`). Really excited to simplify and more strongly model my entities! :)
whirlwind! THANK YOU for finally getting to this I know it's been in your sights for quite some time! Yeah ...not supporting null complex type properties is ...uggh. But I appreciate the problem of implementing it.
@Shay you said this: Note that even with non-owned entities, you can omit having a DbSet of a dependent, making it only reachable via its principal. That should get you to a similar place. Someone can still do dbContext.Set(). For instance, I don't define DbSet properties on very large Domain Models, discovery instead happens through classes that implement IEntityTypeConfiguration. So whichever way, once something is an Entity, it is reachable even if it doesn't have a property of its own on the DbContext.
Great feature! Owned types were always awkward to work with, complex types precisely meet one's expectations as to how these kinds of objects are supposed to behave. So, well done! Such a bummer that nested record types with the primary constructor syntax aren't supported though.
This is - in my opinion - the most important feature EF has added in years (even more so than `ExecuteUpdateAsync`). Really excited to simplify and more strongly model my entities! :)
whirlwind! THANK YOU for finally getting to this I know it's been in your sights for quite some time! Yeah ...not supporting null complex type properties is ...uggh. But I appreciate the problem of implementing it.
Mind blown at 56:45
@Shay you said this:
Note that even with non-owned entities, you can omit having a DbSet of a dependent, making it only reachable via its principal. That should get you to a similar place.
Someone can still do dbContext.Set(). For instance, I don't define DbSet properties on very large Domain Models, discovery instead happens through classes that implement IEntityTypeConfiguration. So whichever way, once something is an Entity, it is reachable even if it doesn't have a property of its own on the DbContext.
Great feature! Owned types were always awkward to work with, complex types precisely meet one's expectations as to how these kinds of objects are supposed to behave. So, well done!
Such a bummer that nested record types with the primary constructor syntax aren't supported though.
It would be really cool to use complex types as strongly typed composite keys.
you know what your talking about !