.NET Data Community Standup - Complex types as value objects in EF8
Ғылым және технология
The Entity Framework team returns with new community standups after a summer break heads-down working on EF8. In this session, we’ll look at the new “complex types” feature in EF8. Complex types do not have a key or any identity outside of the object’s value, but can still be deconstructed by property to map to different columns in the database. This allows either reference or value types to be used as DDD value objects with much better fidelity than when owned types are used. We’ll show examples of using complex types and talk about and answer your questions on the behavioral differences between entity types, owned entity types, complex types, and primitive types.
Chapters:
00:00 Countdown
02:38 Welcome to the .NET Data Community Standup
04:00 State of the Unicorn
06:46 Complex types as value objects overview
11:28 Demo
01:16:12 Limitations of Complex Types
01:23:45 Wrap
Community Links:
learn.microsoft.com/en-us/ef/...
learn.microsoft.com/en-us/ef/...
Featuring: Arthur Vickers, Shay Rojanksy (@shayrojansky)
#EntityFramework #EFCore #DotNet
Пікірлер: 7
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! :)
Mind blown at 56:45
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.
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.
@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.
It would be really cool to use complex types as strongly typed composite keys.
you know what your talking about !