Support for "dynamic" entity models

The goal of this issue is to track and rationalize various levels or flavors of “dynamic behavior” we could attain with EF in the future.

The initial list is based on digesting information provided in various bugs such as #1513 and #2141 as well as conversations with various teams and previous research on feature gaps with other persistence frameworks.

Note that none of this is planned for EF Core 1.0.0 and before we start bringing dynamic features into EF we should probably open more issues and prioritize each individual feature independently. But at least for now should any new “dynamic” scenario be brought to our attention by the community or should our understanding of them improve we can just keep this list up to date:

• ~Shadow objects: (already tracked individually as #749) This is about having certain entities or complex types defined in the model that do not get materialized as user objects but are just tracked as “state” in the DbContext instance. This is useful for such scenarios as link tables in many-to-many associations or any other situation in which there is an entire entity that contains information that EF needs to track but that the user has chosen not to include in the object model.~
• Property bags: Currently the EF Core stack assumes a distinct CLR type is mapped to each distinct entity type (and eventually for complex types) in the entity model and a CLR property for each entity property (minus any shadow property). This could be changed to enable EF to materialize and track simple property bags (e.g. any object that implements IDictionary<string, object> or contains an indexer property or any other mechanism to get and set values based on a property name). Even the name of the entity instance belongs to could become another property in the bag. This feature would make working with entity models that are created programmatically easier because it would remove the need to emit new CLR types for each entity and complex type at runtime. (#9914)
• Dynamic aggregates: Allow the entity type to be determined by the set of contained components (#26123)
• Proper dynamic objects: This refers specifically to supporting entities and complex types in which each specific instance can contain a different set of properties. I anticipate that the most likely path for us to support proper dynamic objects mapped to relational databases could be to serialize the dynamic part of the object into a BLOB or JSON column instead of shredding it into the individual scalar properties. Querying based on standard properties can be enabled and optimized through computed columns and indexing as described in the comments of #2141. Even within this category there are several alternative levels of support which will probably pose different challenges:
  1. Only scalar properties can differ vs. relationships can also differ
  2. Whole dynamic objects vs. “open types” (i.e. dynamic properties are added at runtime to a set of predefined properties).
  3. Property bag representation vs. actual dynamic/ExpandoObject CLR types (the latter can lead to nicer syntax but might be impossible to use in LINQ).

[AcousticGuitar]

Hello, just a thought on this, instead of DB first there could be a JSON or even XML first equivalent.

[smitpatel]

@weitzhandler - Of course, functions related to JSON support on query side would be implemented in #4021 XML could achieve the similar. This also have some overlap with property bag entities. Regardless, most of work here would be about changing the metadata for representation. Query side comes into picture depending on how it is stored on server & what we can translate.