Add instantiation binding interception and use it for proxies #28127
Conversation
| /// </summary> | ||
| public virtual Func<MaterializationContext, object> GetEmptyMaterializer( | ||
| IEntityType entityType) | ||
| => EmptyMaterializers.GetOrAdd( |
There was a problem hiding this comment.
Does this need to be here? By caching in the entity type we can avoid the dictionary lookup
There was a problem hiding this comment.
Storing it in the model means that when services change, the value in the model will still use an interceptor that is no longer configured. And since this is lazy, it means some entity types could have the interceptor, and some not.
That being said, most of the time a new service provider means a new model will be built, so in reality this won't make much difference for most uses. And we have this problem in other places already (for example, the fact that UseXxxProxies() changes the built model) but I was at least trying to be clean here.
There was a problem hiding this comment.
Happy to change it, if you prefer.
There was a problem hiding this comment.
Is this used in any potential hot path? Or are all usages cached anyway?
There was a problem hiding this comment.
It's used when synthesizing join entity instances in navigation fixup. So I highly doubt it is a hot path for anything.
There was a problem hiding this comment.
Then leave it as it. We can always move it later
Part of #626 Part of #15911 Fixes #20135 Fixes #14554 Fixes #24902 This is the lowest level of materialization interception--it allows the actual constructor/factory binding to be changed, such that the expression tree for the compiled delegate is altered. Introduces singleton interceptors, which cannot be changed per context instance without re-building the internal service provider. (Note that we throw by default if this is abused and results in many service providers being created.) The use of this for proxies has two big advantages: - Proxy types are created lazily, which vastly improves model building time for big models with proxies. See #20135. - Proxies can now be used with the compiled model, since the proxy types are not compiled into the model. See
Co-authored-by: Andriy Svyryd <AndriySvyryd@users.noreply.github.com>
Co-authored-by: Andriy Svyryd <AndriySvyryd@users.noreply.github.com>
Co-authored-by: Andriy Svyryd <AndriySvyryd@users.noreply.github.com>
ajcvickers
force-pushed
the
SomeBoysTryAndSomeBoysLie0430
branch
from
dcb0a12
to
b648d07
Compare
Part of #626
Part of #15911
Fixes #20135
Fixes #14554
Fixes #24902
This is the lowest level of materialization interception--it allows the actual constructor/factory binding to be changed, such that the expression tree for the compiled delegate is altered.
Introduces singleton interceptors, which cannot be changed per context instance without re-building the internal service provider. (Note that we throw by default if this is abused and results in many service providers being created.)
The use of this for proxies has two big advantages: