Don’t get me wrong, it’s not perfect. But then again, neither were early mobile phones. However, just like early mobiles, ML1 is more about possibilities and a vision for the future, which it has in spades.
In the previous post we ended up with entities that hide the join entity from the public surface. However, it was not possible to add or removed entities through this public surface. To enable this we need an ICollection implementation that acts as a true facade over the real join entity collection and delegates all responsibilities to that collection.
In the previous post we looked at how many-to-many relationships can be mapped using a join entity. In this post we’ll make the navigation properties to the join entity private so that they don’t appear in the public surface of our entity types. We’ll then add public IEnumerable properties that expose the relationship for reading without reference to the join entity.
As of EF Core 2.0, many-to-many relationships without an explicitly mapped join table are not supported. However, all is not lost. In this series of posts I will show:
- Mapping many-to-many relationships with a join entity/table
- Abstracting/hiding the join entity
- In a simple way for read-only access to the relationship
- In a more involved way that allows entities to be added and removed from each end
EF Core provides a variety of ways to start tracking entities or change their state. This post gives a brief overview of the different approaches.
As developers on the EF team it is often useful to see what is in the metadata model. To facilitate this, the model and all other metadata elements are able to generate a “debug view” which provides lots of useful information about the metadata in a terse but human-readable form.