Lazy-loading proxies package #10720
Lazy-loading proxies package #10720
Conversation
|
Should this be called "CastleProxies"? Could it support different proxy impls? Or would they be separate packages? |
| => Expression.Call( | ||
| EntityMaterializerSource.TryReadValueMethod.MakeGenericMethod(ConsumedProperty.ClrType), | ||
| { | ||
| var property = ConsumedProperties.First(); |
| /// This API supports the Entity Framework Core infrastructure and is not intended to be used | ||
| /// directly from your code. This API may change or be removed in future releases. | ||
| /// </summary> | ||
| public static readonly ProxyFactory Instance = new ProxyFactory(); |
There was a problem hiding this comment.
D.I. enabled the factory
| /// </summary> | ||
| public static readonly ProxyFactory Instance = new ProxyFactory(); | ||
|
|
||
| private readonly ProxyGenerator _generator = new ProxyGenerator(); |
Part of #10509, #3797. This change adds a new package--Microsoft.EntityFrameworkCore.Proxies--that contains a lazy-loading proxy implementation making use of the EF lazy-loading infrastructure and the Castle.Core proxies package. Current plan is for this to ship on NuGet as an optional package for use with EF. To use in a normal application, just add a call to `UseLazyLoadingProxies()` on the DbContext options builder. There are also `context.CreateProxy()` methods for creating stand-alone proxy instances if needed. Entity types must be public and navigation properties must be virtual. Also, the entity type and constructor must be "visible" to the castle proxies assembly, which usually means public, but could mean internal if "InternalsVisibleTo" is used. Exceptions are thrown if these requirements are not met--you don't just not get a proxy like in EF6. Note that this is an optional package for EF that we chose to create because the infrastructure in place made it easy to do so. It does not preclude a Roslyn-based rewriting solution in the future.
ajcvickers
force-pushed
the
ThisKikiIsMarvelous0111
branch
from
6566362 to
972b71f
Compare
|
@ajcvickers , I ask why you when using: and use the AsNoTracking Ex: LazyLoad is simply ignored. |
|
@ralmsdeveloper Loading of related entities (with .Load) does not work for entities that are not being tracked: see #10042. Since lazy loading is just a way of calling .Load it also doesn't support this. It's not even clear that this should work--I believe for 2.1 we will just make sure that it throws. In the future it could be made to work, but I doubt it will make it into 2.1. |
|
Thanks @ajcvickers , Congratulations, this will eliminate some bad reviews! |
Part of #10509, #3797.
This change adds a new package--Microsoft.EntityFrameworkCore.Proxies--that contains a lazy-loading proxy implementation making use of the EF lazy-loading infrastructure and the Castle.Core proxies package. Current plan is for this to ship on NuGet as an optional package for use with EF.
To use in a normal application, just add a call to
UseLazyLoadingProxies()on the DbContext options builder.There are also
context.CreateProxy()methods for creating stand-alone proxy instances if needed.Entity types must be public and navigation properties must be virtual. Also, the entity type and constructor must be "visible" to the castle proxies assembly, which usually means public, but could mean internal if "InternalsVisibleTo" is used. Exceptions are thrown if these requirements are not met--you don't just not get a proxy like in EF6.
Note that this is an optional package for EF that we chose to create because the infrastructure in place made it easy to do so. It does not preclude a Roslyn-based rewriting solution in the future.