Fully implement entire entities in shadow state

[ajcvickers]

That is, entities not backed by any CLR type. Also see #748.

[rjperes]

May I ask what is the gain of this? Does this feature exist in any ORM? I know this is going to be used for M:M mapping in EF Core, but other that that, I honestly can't see the point. Thanks! :-)

[divega]

@rjperes In general we use shadow sate to reduce the coupling between the domain model the application reasons about and the extra information EF Core might need to track and reason about. This allows for more flexibility on the shape of the types while maintaining how EF Core reasons about the model at runtime relatively simple and based on a relatively small number of different concepts.

For individual properties in shadow state one of the main examples is how EF Core always reasons about relationships between objects in terms of foreign key properties, but CLR types that participate in those relationships don't need to contain the FKs.

For full entities in shadow state, the main two potential scenarios to come to mind are:

1. The join entity in many-to-many associations (which you already mentioned)
2. Extensibility scenarios in which collections of new data can be added to an entity (e.g. by a user) without having to define a new CLR type to store the new data.

In both cases not having a type in the domain model representing this data is a developer's choice.

[BradBarnich]

for my use case, I have audit tables that are maintained by trigger. I wanted the tables to be part of migrations so I did this:

foreach ( var entityType in modelBuilder.Model.GetEntityTypes().ToArray() )
{
    var auditEntity = modelBuilder.Entity( entityType.Relational().TableName + "History" );
    foreach ( var property in entityType.GetProperties() )
    {
        auditEntity.Property( property.ClrType, property.Name );
    }
    auditEntity.Property( typeof( DateTime ), "ValidTo" );
    auditEntity.HasKey( "ID", "ValidTo" );
}

Also had to make a custom model validator that skips EnsureNoShadowEntities, but then it works.

[AndriySvyryd]

We should completely drop support for shadow state entities in favor of property bag entities #9914 as they are easier to work with as a customer and would require less code changes to implement.

[ajcvickers]

Closing as this particular idea (entities without any CLR object) may now not be needed since something like property bags (or even object entities with shadow properties) would cover the cases where this was thought to be useful.

[lakeman]

It's a little silly that I need to define something like internal class Dummy<T>{} which I only intend to use for audit table migrations like the above example.

If you aren't going to implement shadow entities, then why not remove methods like IMutableModel.AddEntityType(string name), since their use isn't supported.

[AndriySvyryd]

@lakeman Currently Migrations use shadow entity types to decouple the snapshot from the implementation.
When property bag entities are implemented AddEntityType(string name) will probably change meaning.