What is Owned Entity? When and why to use Owned Entity in Entity Framework Core?

回答1

What does this look like without owned entities?

If you create an entity, Job, in EF Core that points to a complex object, HiringManagerName, in one of the properties, EF Core will expect that each will reside in a separate table and will expect you to define some sort of relationship between them (e.g. one-to-one, one-to-many, etc.).

When retrieving Job, if you want to explicitly load the values of HiringManagerName as well, you'd have to use an explicit Include statement in the query or it will not be populated.

var a = dbContext.Jobs
.Include(b => b.HiringManagerName) //Necessary to populate
.ToListAsync();

But because each is thought to be a separate entity, they will be required to expose keys and you'll have to configure foreign keys between each.

What is an owned entity?

That's where [Owned] types come in (see docs). By marking the child class with the [Owned] attribute, you leave the explicit handling of that relationship to EF Core to manage and no longer have a need to define the key(s)/foreign key(s) on the owned type. Same if you point to a collection of your owned type - you no longer need to deal with navigation properties on either class to describe the relationship.

EF Core also supports queries against these owned types, as in:

var job = context.Jobs.Where(a => a.HiringManagerName.First == "fingers10").FirstOrDefaultAsync();

Now, it comes with two important design restrictions described in the docs (but elaborated on here):

• You cannot create a DbSet for the owned type

This means that you cannot subsequently do a DB call with:

dbContext.HiringManagerNames.ToListAsync();

This will throw because you are expected to simply retrieve the value as part of a call to:

dbContext.Jobs.ToListAsync();

Unlike the first example I gave, HiringManagerNames no longer needs to be explicitly included and will instead be returned with a call to the Jobs DbSet<T>.

• Cannot call Entity<T> with an owned type on ModelBuilder

Similarly, you cannot reference your owned type in the ModelBuilder to configure it. Rather, if you must configure it, do so through the configuration against your Jobs entity and against the owned property, e.g.:

modelBuilder.Entity<Job>().OwnsOne(a => a.HiringManagerNames).//Remaining configuration

So when should I use owned entities?

If you've got a type that's only ever going to appear as a navigation property of another type (e.g. you're never querying against it itself as the root entity of the query), use owned types in order to save yourself some relationship boilerplate.

If you ever anticipate querying the child entity independent of the parent, don't make it owned - it will need to be defined with its own DbSet<T> in order to be called from the context.

回答2

While @Whit Waldo explanation is great with respect to technical ef core, we should also try to understand from Domain Driven Design perspective.

Lets observe the classes mentioned in the question itself

public class Job : Entity

and

public class HiringManagerName : ValueObject

Take a note at Entity and ValueObject. Both of them are DDD concepts.

Identity matters for entities, but does not matter for value objects.

Take a look at this write up from Vladimir Khorikov for a more extensive explanation.

I past the summary bullets here.

• Entities have their own intrinsic identity, value objects don’t.

• The notion of identity equality refers to entities; the notion of structural equality refers to value objects; the notion of reference equality refers to both.

• Entities have a history; value objects have a zero lifespan.

• A value object should always belong to one or several entities, it can’t live by its own.

• Value objects should be immutable; entities are almost always mutable.

• To recognize a value object in your domain model, mentally replace it with an integer.

• Value objects shouldn’t have their own tables in the database.

• Always prefer value objects over entities in your domain model.

So a value object is owned by an entity. So how do we achieve that using EF Core? Here comes the concept of Owned entities. Now go back and read @Whit Waldo answer.