Initial implementation of lazy-loading and entities with constructors

[ajcvickers]

Parts of issues #3342, #240, #10509, #3797

The main things here are:

• Support for injecting values into parameterized entity constructors
  • Property values are injected if the parameter type and name matches
  • The current DbContext as DbContext or a derived DbContext type
  • A service from the internal or external service provider
  • A delegate to a method of a service
• Use of the above to inject lazy loading capabilities into entities

For lazy loading, either the ILazyLoader service can be injected directly, or a delegate can be injected if the entity class cannot take a dependency on the EF assembly--see the examples below.

Currently all constructor injection is done by convention.

Remaining work includes:

• API/attributes to configure the constructor binding
• Allow factory to be used instead of using the constructor directly. (Functional already, but no API or convention to configure it.)
• Allow property injection for services
• Configuration of which entities/properties should be lazy loaded and which should not

Examples

In this example EF will use the private constructor passing in values from the database when creating entity instances. (Note that it is assumed that _blogId has been configured as the key.)

public class Blog
{
    private int _blogId;

    // This constructor used by EF Core
    private Blog(
        int blogId,
        string title,
        int? monthlyRevenue)
    {
        _blogId = blogId;
        Title = title;
        MonthlyRevenue = monthlyRevenue;
    }

    public Blog(
        string title,
        int? monthlyRevenue = null)
        : this(0, title, monthlyRevenue)
    {
    }

    public string Title { get; }
    public int? MonthlyRevenue { get; set; }
}

In this example, EF will inject the ILazyLoader instance, which is then used to enable lazy-loading on navigation properties. Note that the navigation properties must have backing fields and all access by EF will go through the backing fields to prevent EF triggering lazy loading itself.

public class LazyBlog
{
    private readonly ILazyLoader _loader;
    private ICollection<LazyPost> _lazyPosts = new List<LazyPost>();

    public LazyBlog()
    {
    }

    private LazyBlog(ILazyLoader loader)
    {
        _loader = loader;
    }

    public int Id { get; set; }

    public ICollection<LazyPost> LazyPosts
        => _loader.Load(this, ref _lazyPosts);
}

public class LazyPost
{
    private readonly ILazyLoader _loader;
    private LazyBlog _lazyBlog;

    public LazyPost()
    {
    }

    private LazyPost(ILazyLoader loader)
    {
        _loader = loader;
    }

    public int Id { get; set; }

    public LazyBlog LazyBlog
    {
        get => _loader.Load(this, ref _lazyBlog);
        set => _lazyBlog = value;
    }
}

This example is the same as the last example, except EF is matching the delegate type and parameter name and injecting a delegate for the ILazyLoader.Load method so that the entity class does not need to reference the EF assembly. A small extension method can be included in the entity assembly to make it a bit easier to use the delegate.

public class LazyPocoBlog
{
    private readonly Action<object, string> _loader;
    private ICollection<LazyPocoPost> _lazyPocoPosts = new List<LazyPocoPost>();

    public LazyPocoBlog()
    {
    }

    private LazyPocoBlog(Action<object, string> lazyLoader)
    {
        _loader = lazyLoader;
    }

    public int Id { get; set; }

    public ICollection<LazyPocoPost> LazyPocoPosts
        => _loader.Load(this, ref _lazyPocoPosts);
}

public class LazyPocoPost
{
    private readonly Action<object, string> _loader;
    private LazyPocoBlog _lazyPocoBlog;

    public LazyPocoPost()
    {
    }

    private LazyPocoPost(Action<object, string> lazyLoader)
    {
        _loader = lazyLoader;
    }

    public int Id { get; set; }

    public LazyPocoBlog LazyPocoBlog
    {
        get => _loader.Load(this, ref _lazyPocoBlog);
        set => _lazyPocoBlog = value;
    }
}

public static class TestPocoLoadingExtensions
{
    public static TRelated Load<TRelated>(
        this Action<object, string> loader,
        object entity,
        ref TRelated navigationField,
        [CallerMemberName] string navigationName = null)
        where TRelated : class
    {
        loader?.Invoke(entity, navigationName);

        return navigationField;
    }
}

[AndriySvyryd]

If there are multiple bindable constructors with the same number of parameters we should throw instead of arbitrarily selecting one

[ajcvickers]

Done

[AndriySvyryd]

This could bind several parameters to the same property if they only differ in case. We can choose to just throw in that case.

[ajcvickers]

Discussed and changed the matching to use the same rules as for fields, but not preventing the same property being bound to multiple parameters.

[AndriySvyryd]

Add lazy loading to Blog and Post in MigrationsModelDifferTest to ensure nothing blows up in data seeding

[ajcvickers]

Added lazy loading to MigrationsModelDifferTest

[anpete]

@ajcvickers Typo

[anpete]

@ajcvickers
It would be slightly more query-idiomatic to take QueryContext here. We could also introduce a MaterializationContext type here that so that the delegate would be Func<MaterializationContext, object>. The advantage would be to simplify further changes and to DRY things up a bit - Changes here seem pretty viral and unpleasant.

[ajcvickers]

Discussed with @anpete and created issue #10641