DI - resolving instance using parameter (Prism using DryIoc)

Question

I've been searching over the web how could I resolve instance using Prism DryIOC that uses parameter during runtime, but to luck yet.

For example, I have a class:

internal sealed class ItemInfoHelper : IItemInfoHelper
{
    //ctor
     public ItemInfoHelper(Item item) {...}
     public string GetSomething() {...}
}

And in registering service I need to register it.

protected override void RegisterTypes(IContainerRegistry containerRegistry)
{
    containerRegistry.Register<IItemInfoHelper, ItemInfoHelper>();
}

If I do this, when I resolve it somewhere like:

var helperInstance = container.Resolve<IItemInfoHelper>();

it will be obviously resolved using empty Item (using default Item constructor). I have seen a lot of examples that register instances using some parameters that are known at compile time. But the case is that I would like to resolve instance being initialized dynamically using Item that would be a different one in different places (i.e. known at runtime only).

Is there a way to register/resolve it using such behavior if I use Prism + DryIoc? Thanks in advance.

Have you read [this advice](blogs.cuttingedge.it/steven/p/runtime-data/)? — Steven, Feb 09 '21 at 08:07

dadhi · Accepted Answer · 2021-02-09T06:08:07.317

3

The simplest type-safe way to do so is to resolve the function of item:

var getHelperInstance = container.Resolve<Func<Item, IItemInfoHelper>>();
var helperInstance = getHelperInstance(myItem);

edited Feb 09 '21 at 06:08

answered Feb 09 '21 at 05:56

dadhi

4,807
19
25

Just asking out of curiosity, will this work if the `ItemInfoHelper` needs more parameters (dependencies) than just the `Item`? Will those be automatically filled in by the container? – Haukinger Feb 09 '21 at 07:25
@dadhi, thanks a lot! Works like a charm. You've created a great product, DryIoc is something awesome :) – Oleksii Feb 09 '21 at 08:38
@Haukinger , yes, if there are multiple parameters - just extend Func to get more params. Works perfectly, just tested this out. – Oleksii Feb 09 '21 at 08:39
2

@Haukinger, Yes, the rest of the parameters are injected from the registrations. More in the docs https://github.com/dadhi/DryIoc/blob/master/docs/DryIoc.Docs/Wrappers.md#func-of-a-with-parameters – dadhi Feb 09 '21 at 15:19
@dadhi , just curious - if we resolve helperInstance like that, is there some mechanism that restricts us from using instance initialized with empty Item? Of course we can check if Item is not null at runtime (or in tests), but when registering IItemInfoHelper is there a way to say that Item parameter would be required. As I see now, there is no such mechanism, but maybe I'm wrong – Oleksii Feb 10 '21 at 08:30
The same situation as above may happen if developer would decide to inject IItemInfoHelper to ViewModel constructor. So just interesting to know. – Oleksii Feb 10 '21 at 08:38
@Oleksii It is vice versa - The original exception is such a **default** mechanism. You may override it with the Func (saying I will provide the item) or making the item the optional parameter `TItem item = null` (DryIoc supports the optionals) – dadhi Feb 10 '21 at 10:36

DI - resolving instance using parameter (Prism using DryIoc)

1 Answers1