C# DI Func factory without registering Func?

Question

I'm not sure whether SO is the correct place to ask the question, but existing SO questions don't help much(such as Autofac and Func factories), nor does Autofac document help, and google searching autofac factory func couldn't get the answer either. I have basic knowledge of DI and IoC.

The primary goal was trying to understand a ~1k stared github repo ReactiveTrader, which demonstrates using reactive extension in real world application. I've successfully built(though took some effort) and ran both the server and client. and it is really excellent learning material!

While reading the code, I was stucked by several constructors injection like this:

public SpotTilesViewModel(IReactiveTrader reactiveTrader,
    Func<ICurrencyPair, SpotTileSubscriptionMode, ISpotTileViewModel> spotTileFactory,
    IConcurrencyService concurrencyService,
    ILoggerFactory loggerFactory)

There's a Func<TSource1, TSource2, TTarget> called somefactory in the constructor, there's no explicit reference to the constructor(so it must be DI right?), and there's no code registering the Func type(which is used in above SO answer I mentioned):

builder.RegisterType<Func...

So I'm very curious about why such Func<> factory in constructor is useful, and how does it work, and if possible, could you give a simplest demo? Many thanks!

i'm not sure about the scenario/project you mentioned. I'm using this approach when i need multiple instances (the constructor only initiates once per class) - this is a common requirement when using Entity Framework — Joel Fleischman, Sep 07 '20 at 04:06
have you reviewed already https://autofaccn.readthedocs.io/en/latest/advanced/delegate-factories.html ? — Joel Fleischman, Sep 07 '20 at 04:34

score 2 · Accepted Answer · answered Sep 07 '20 at 14:26

I'm neither familiar with that particular feature of Autofac nor the code base to which you refer, but some DI Containers support automatic generation of functions. After all, a function (or delegate) is just an anonymous interface; it's another way to model polymorphism.

A delegate with the type Func<ICurrencyPair, SpotTileSubscriptionMode, ISpotTileViewModel> is a function that will return an ISpotTileViewModel object if you supply an ICurrencyPair and a SpotTileSubscriptionMode. That's isomorphic to an interface like this:

public interface ISpotTileViewModelFactory
{
    ISpotTileViewModel Create(ICurrencyPair pair, SpotTileSubscriptionMode mode);
}

Some DI Containers can autogenerate such factory interfaces as well. The algorithm goes something like this:

Keep in mind that at the heart of a DI Container is a table of mappings from polymorphic types to concrete types. For instance, the interface ISpotTileViewModel is mapped to a concrete type. Skimming the GitHub repository for the code base in question, I guess that the SpotTileViewModel class is the concrete type paired with ISpotTileViewModel.

The SpotTileViewModel class has one constructor. Thus, in order to be able to create an instance of it, the DI Container must analyse the constructor to figure out how to invoke it. It looks like this:

public SpotTileViewModel(
    ICurrencyPair currencyPair,
    SpotTileSubscriptionMode spotTileSubscriptionMode,
    Func<ICurrencyPair, SpotTileSubscriptionMode, ISpotTileViewModel, ISpotTilePricingViewModel> pricingFactory,
    Func<ITrade, ISpotTileViewModel, ISpotTileAffirmationViewModel> affirmationFactory,
    Func<string, ISpotTileViewModel, ISpotTileErrorViewModel> errorFactory,
    Func<ISpotTileConfigViewModel> configFactory)

It looks like a bit of a mouthful, but there's the ICurrencyPair and SpotTileSubscriptionMode, as well as four other functions.

The DI Container must now figure out how it can (if possible) create each of those six constructor arguments. It proceeds recursively through its table of mappings until it figures it out or has to give up. This process is what Steven van Deursen and I call Auto-Wiring in DIPPP.

My guess is that the DI Container has mappings for most of the polymorphic types in play here: ISpotTileAffirmationViewModel, ISpotTileErrorViewModel, and so on. Possible exceptions (but I'm speculating here) are exactly ICurrencyPair and SpotTileSubscriptionMode. But then, if you supply those two missing pieces, the DI Container knows how to map all the other pieces of the puzzle, and via Reflection Emit, it's able to 'code at run time' a function with the type Func<ICurrencyPair, SpotTileSubscriptionMode, ISpotTileViewModel>.

thanks for your detailed explainations! Could you give a simple example(pseudo code is enough) showing the **benefit** of using DI generated Func<> factories? what function cannot be, or is inconveinent to fulfil without it? — Lei Yang, Sep 07 '20 at 15:44
@LeiYang A long time ago I gave [an answer about using functions for DI](https://stackoverflow.com/a/8288592/126014), but I think that [this short article series](https://blog.ploeh.dk/2017/01/27/from-dependency-injection-to-dependency-rejection) better reflects my current position. In short, I'm not a fan of injecting functions. — Mark Seemann, Sep 07 '20 at 16:53
thanks, i think i need read more books about DI like the one you mentioned. I don't like th e Func factory either. — Lei Yang, Sep 08 '20 at 01:11

C# DI Func factory without registering Func?

1 Answers1