Simplified parametric Func-based injection

[Serg046]

Consider you have a service that should receive some dependency at runtime:

class Foo(string runtimeArg, IBar bar) : IFoo {}
class Baz(Func<string, IFoo> factory) {
    var foo1 = factory("1");
    var foo2 = factory("2");
}

The only current way to achieve it is to do something like this which is rather verbose. Another disadvantage is that you will have to register your argument for the whole composition root with either the name or tag so that it could be linked into another service unexpectedly.

DI.Setup()
    .Bind<IBar>().To<Bar>()
    .Bind<string>().To<string>("runtimeArg")
    .Bind<Func<string, IFoo>>().To<Func<string, IFoo>>(ctx => runtimeArg => {
        ctx.Inject<Foo>(out var foo);
        return foo;
    })

The proposal is to make it less verbose. Ideally you want to map IFoo to Foo without any additional steps required like it is usually done in classic dynamic containers without checks.

DI.Setup()
    .Bind<IBar>().To<Bar>()
    // 1. This will obviously fail referring to runtimeArg, we should keep it
    // .Bind<IFoo>().To<Foo>()
    // 2. This will complain that Func<string, IFoo> is not implemented by Func<string, Foo>
    // .Bind<Func<string, IFoo>>().To<Func<string, Foo>>()
    // 3. Some syntax like this could work
    .Bind<IFoo>().AsFunc().To<Foo>() // or AsFactory(), or AsFunc<string>() or just something similar

The hint will tell the gen to do the following:

1. Get the dependency list [string,IBar].
2. Scan the composition to see if there are registered deps [IBar].
3. Exclude registered deps from the list [string].
4. Register a func of service with remaining deps instead of the initial service. Func<string, IFoo> instead of IFoo.

[NikolayPianikov]

@Serg046 When some dependency is added that has not been defined, it can break a lot of things and it will be difficult to understand which Func<, , ,> should be injected. Also the sequence of passing parameters to Func is not clear. And what if you have several parameters of the same type, but which have different purposes?

[NikolayPianikov]

.Bind<IFoo>().AsFunc().To<Foo>()
can be replaced with
.Bind<IFoo>().ToFactory<Foo>()

[Serg046]

When some dependency is added that has not been defined, it can break a lot of things

True, I am really worry that I don't see something right now. But from the other hand, I don't want to spend time doing something that couldn't even make sense

it will be difficult to understand which Func<, , ,> should be injected

The current proposal is quite simple and probably naive. You just exclude registered types and put remaining ones as Func type arguments.

class Foo(string first, string second, IBaz baz, string third, int number, IBar bar) : IFoo {}

So here you inject Func<string, string, string, int, IFoo>

DI.Setup
    .Bind<IBaz>().To<Baz>()
    .Bind<IBar>().To<Bar>()
    .Bind<IFoo>().ToFactory<Foo>()

And below is a complete analog, you can think like ToFactory is syntax sugar for this (with better isolation).

DI.Setup
    .Bind<IBaz>().To<Baz>()
    .Bind<IBar>().To<Bar>()
    .Bind<string>().To<string>("first")
    .Bind<string>().To<string>("second")
    .Bind<string>().To<string>("third")
    .Bind<int>().To<int>("number")
    .Bind<string, string, string, int, IFoo>().To<string, string, string, int, IFoo>(
        ctx => (first, second, third, number) => {
            ctx.Inject<Foo>(out var foo);
            return foo;
    })

Also the sequence of passing parameters to Func is not clear

I'd keep the same order as in the implementation type constructor skipping registered stuff.

what if you have several parameters of the same type, but which have different purposes

It seems like that's not a Pure.DI responsibility, the developer decides what to pass where.

class MySuperService(Func<string, string, string, int, IFoo> createFoo, [Tag("DI tag")]string staticArg)
{
    var foo1 = createFoo("I decide to pass it here", staticArg, "third", 5);
    var foo2 = createFoo("1", "2", "3", 4);
}

[Serg046]

Btw, let me also share another disadvantage I faced recently with the current existing approach:

using Mono.Cecil;

class SomeService(MethodReference method) {}
class AnotherService(MethodDefinition method) {}

DI.Setup
    .Bind<MethodReference>().To<MethodReference>("method")
    .Bind<Func<MethodReference,SomeService>>().To<Func<MethodReference,SomeService>>(ctx => method {
        ctx.Inject<SomeService>(out var service); return service;
    })

    .Bind<MethodDefinition>().To<MethodDefinition>("method")
    .Bind<Func<MethodDefinition,AnotherService>>().To<Func<MethodDefinition,AnotherService>>(ctx => method {
        ctx.Inject<AnotherService>(out var service); return service;
    })

This cannot work because MethodReference is inherited from MethodDefinition that's why you are forced to use tags or other names. If we had a better isolation, that wouldn't be the case.

[NikolayPianikov]

I'm working on task #88 right now. And within this task, there is such an opportunity. So far there are a lot of problems and I'm in the process.

[Serg046]

That's quite a good compromise. Significantly less verbose and well isolated. Eager to see it released. Feel free to close the current proposal and ping me once/if you want to resume it.

[NikolayPianikov]

I'm not sure I'll be able to realize it yet. Since this approach creates a number of uncertainties. So we don't need to close this ticket yet.

[NikolayPianikov]

@Serg046 Please review the API for "Overrides". Here are examples:

• Overrides
• Func with arguments

Version 2.1.60-beta2 is available, so you can give it a try.

[Serg046]

Thank you Nikolay, that's exactly what I need.

As for the current demo version, I experience some unexpected difficulty. I cannot replace

.Bind<MethodReference>().To<MethodReference>("patch")
            .Bind<Func<MethodReference, IPatchMember>>().To<Func<MethodReference, IPatchMember>>(ctx => patch =>
            {
                ctx.Inject<PatchMethod>(out var member);
                return member;
            })

https://github.com/Serg046/AutoFake/blob/v1-dev/AutoFake/CompositionRoot.cs#L22-L27
with something like this

.Bind<Func<MethodReference, IPatchMember>>().To<Func<MethodReference, IPatchMember>>(ctx => patch =>
            {
                ctx.Override(patch);
                ctx.Inject<PatchMethod>(out var member);
                return member;
            })

Although I managed to use "override" in other places (and new func feature too).

[NikolayPianikov]

Added PR.

I still want to finalize the Func<T, T, T...> approach

[NikolayPianikov]

Done, it looks much better