EF Core 8 Finally Fixes Value Objects

Hi Milan, do you achieve that complex property works with typed ID, like BookId(Guid ID)?

Quick question re: list of complex types. If a complex type is mapped to columns in a table alongside the entity they belong to, how would you map a list of those to the table? Isn't that exactly what navigation properties are for?

It's not yet full supported. Complex type collection support is not ready. Check the issue 31237 and vote!

I don't understand what is the meaning of the Owned types

I feel bad for people getting obsessed by the business domain trivial example and not trying to understand this new feature.. Maybe you should post a video on active listening Milan 😂😂

I mean, there are other great contents on value objects use cases and benefits.

Having struggled with poor implementations and complexity of value object persistence in efcore, I'm quite excited by this new feature! Even if in the meantime we'll have to handle collections manually..but that's a good step forward and I'll use this for sure 😊

All in all, another handy feature to keep in our toolbelt 👍

Thanks for your hard work Milan 🙏

Its AWESOME ! thank you so much for your content <3

.NET stare

It's not coupling if you call it a "Value Object"

There is no Id if EF Core hides it from you.

Right?

There is no such thing as a "Value Object" . If it is stored in ANY type of database and gets retrieved, then it has an associated Id. Period. This is definitional. Arthur Vickers effectively said this in an EF Core stand up.

Nothing was "fixed". Coupling and magical thinking were enabled.

Stop the madness, Milan.

Must the columns be author_? Can this be implemented in db first scenario where the existing columns may not follow that naming convention?

Thanks for the video Milan! The possibility o fetching only value object data from the table is really great 🔥

Are EF 8 value objects tracked the same as "entity" entities? 🤔

Will this avoid the exception when using stringly typed ids since we use them as both value/nonentity types for the aggregate but as entity types when we reference them from another aggregate?

Finally!

I do not see the point. what does this solve? Why not have two real classes and tables? In real life an author writes 1 or more books. Why would you store the author multiple times? My advise is to not use any magic in EF core. Also implicit many2many tables that can be created by EF. Just write your own many2many class, you can then for instance put the timestamp and userid on it, who added that connection. Your are then in full control of everything.

awesome

how would collections work with complex types? shouldnt a new table be added for that since not all db providers support the array type

For all that says this example does not suit the feature, you may be right. It doesn't metter but the explication, that was imo exaustive.

Here is another simple example:
In case of an order we may have a shipping address related to it. It's not ideal to save the Id of the customer address but the information itself at time t.
This because the address could potentially be removed from the customer entity, or even modified. Best thing is to store it separately, as this case, in a complex object, also to sepate concerns in class.

Thank you Milan for all your videos.

Couldn't you just have simply used conversion before?
IE:
builder.Property(x => x.SomeProperty).HasConversion(x => x.Value, x => new ValueObject(x));

Dicha funcionalidad existía en EF 6, por lo tanto ver que EF Core 8 ya la tiene me motiva a migrar mi aplicación "legacy".

Doesn't this remind [ComplextType] attribute in EF 4.0?

I am glad that this has been fixed

Collections for value objects would really be useful for my use case

finally we can have a good EF features to support define & map value object to the database 😄

Very informative video! Too bad it'll take a while before I get to use EFCore 8 at my current job. Stubbled upon the issues mentioned in the video quite a few times with older EF versions. Keep up the good work :)

the poor example. didn’t show all wide spectrum of this update

Thanks! It's very cool feature

I believe you but I don't understand why that errored before? Because of the reference? It has no PK. I did notice seeding those owned types needed to be initialized as anonymous types.
I think you could use Records as well, that brings along other complications ofc.
I would like to learn more about those "nvarchar(max)", how to globally limit that, if you should limit that. Or how optimized that is by default.

Hey, another great video! But I am not getting the point of having a collection of complex types inside the entity? How this collection will be mapped into the database?

This is a very poor example of a Value Object. I think the feature might be useful in some scenarios, but this example is not one. It would be nice to see a real-world example instead.

I like this feature much, hope collections will be supported too until EF 8 release

I have never used that. Autors should be stored is diffrent table and reused (many to many).
This "own" thing looks like something against database normalization.

Changing the last name of the author and updating it in all books does not make sense, as ValueObjects should be immutable (well, at least from a DDD perspective).
Nice feature demo though, I can't wait to clean up my dbcontext configurations.

Finally!!! 🤩
Thanks Milan!

First!😅