DryIoc：不同工厂的不同依赖条件答案

【问题标题】：DryIoc: Different Dependency from different Factory by ConditionDryIoc：不同工厂的不同依赖条件
【发布时间】：2017-11-29 14:58:43
【问题描述】：

我尝试过这样的事情：

container.Register<IFactory, WebFactory>(
    serviceKey: "t");

container.Register<IConfigurationProvider>(made: Made.Of(
    r => ServiceInfo.Of<IFactory>(serviceKey: "t"), 
    f => f.Create()), setup: Setup.With(condition:
        req => req.Parent.Enumerate().Any(p => 
            p.ServiceType.Namespace.StartsWith("Namespace"))));


container.Register<IFactory, OtherFactory>(
    serviceKey: "c");

container.Register<IConfigurationProvider>(made: Made.Of(
    r => ServiceInfo.Of<IFactory>(serviceKey: "c"), 
    f => f.Create()), setup: Setup.With(condition:
        req => req.Parent.Enumerate().Any(p => 
            p.ServiceType.Namespace.StartsWith("OtherNamespace"))));


container.Register<IFactory, DefaultFactory>();
container.Register<IConfigurationProvider>(made: Made.Of(
    r => ServiceInfo.Of<IFactory>(), f => f.Create()));         
container.Register<IConfigured, Configured>(made: Made.Of(() =>
    new Configured(Arg.Of<IConfigurationProvider>())));


namespace Namespace {
    class MyService {
        MyService(IConfigured configured) {
        }
    }
}


namespace OtherNamespace {
    class MyOtherService {
        MyOtherService(IConfigured configured) {
        }
    }
}

但是 DryIoc 只是注入了最后一个注册的 IConfigurationProvider 并忽略了条件。我简化了大量代码并替换了配置中的名称（是的，服务类已注册）。

条件和 RequestInfo 的更好文档会很好。

编辑：我现在假设问题是我的工厂默认注册，而 DryIoc 只使用最后一个。

EDIT2：RequestInfo 到底代表什么？被请求的那个人？所以这意味着已配置？还是 RequestInfo.Parent 已配置？枚举什么？整个依赖树？

【问题讨论】：

你从哪里使用容器，来自 Asp.Net Core？
RequestInfo 表示手头注入依赖的信息。父级正在注入/使用服务。 Enumerate 遍历所有父级从依赖项到解析根。
是的，来自带有 services.AddControllersAsServices() 的 ASP.net Core。我的示例中的“注入依赖项”是什么？ Parent 是 MyService 还是 MyOtherService 实例？
关于 IConfigured 依赖，它们都是父级，但在不同的请求链上
这没有帮助。两者的配置几乎相同，具有相同的类结构但名称不同。如果我打电话给 req.Parent 在我的例子中到底是什么？什么代表req？ req == IConfigurationProvider 和 req.Parent == IConfigured 和 req.Parent.Parent == MyService / MyOtherService?

标签： dryioc

【解决方案1】：

这可能是与实例工厂一起使用的条件错误。需要时间找出答案。

目前的解决方法（DryIoc 2.12.5）将在有条件的设置中添加asResolutionCall: true。实际上它不应该是必需的，并且 DryIoc 应该在幕后自动执行此操作以防止缓存第一个条件结果。这就是为什么它可能是一个错误。

这是来自comments chat 的working sample。

关于问题中的代码，有条件的注册应该像这样修改（为了可读性重新格式化了一下）：

container.Register<IConfigurationProvider>(
    made: Made.Of(r => ServiceInfo.Of<IFactory>(serviceKey: "t"), f => f.Create()), 
    setup: Setup.With(asResolutionCall: true,
        condition: r => r.Parent.Enumerate().Any(
             p => p.ServiceType.Namespace.StartsWith("Namespace"))));

container.Register<IConfigurationProvider>(
    made: Made.Of(r => ServiceInfo.Of<IFactory>(serviceKey: "c"), f => f.Create()), 
    setup: Setup.With(asResolutionCall: true,
        condition: r => r.Parent.Enumerate().Any(
             p => p.ServiceType.Namespace.StartsWith("OtherNamespace"))));

【讨论】：

看来，asResoultionCall 的性能比较差，或者是我的实例很贵。但是如果我将我的 IConfigurationProvider-Register-Statement 设置为重用：Reuse.Singleton，注册似乎从未使用过，但 IDependOnDependency 有一个短暂的重用。
性能会更差，是的，正如你所预料的那样。我将使用与 Singleton.Reuse 聊天中的示例进行查看
对不起，Reuse.Singleton 工作正常。似乎是我的错误配置。感谢您的出色工作。