Ninject提供程序无法解析在命名范围内注册的类型

时间:2014-09-10 14:39:23

标签: ninject ninject-extensions

我正在使用NamedScoped Ninject扩展来尝试创建每次由容器构造命令处理程序时构造的对象图。换句话说,我想为每个可能由其相应处理程序处理的命令创建一个新的对象图。

我在注册我的"命令处理程序"时使用了.DefinesNamedScope(" TopLevelOrhcestrator")绑定。因为它们是命令处理的顶级。

此命名范围中的类型需要在已在此命名范围中注册的类型上注入方法调用的结果。我认为最好的方法是使用ninject提供程序。 在提供程序中我试图解析类型,希望我可以调用它上面的方法传递到我在这个命名范围内创建的另一个对象。我遇到的问题是,当我向客户提供商内部的实例询问IContext时,我得到一个异常,说明没有匹配的范围可用,并且该类型被声明为InNamedScope(TopLevelOrchestrator)。

context.Kernel.Get<TypeAlreadyRegisteredInScope>().MethodThatGetsAnotherDependency()

当它们在命名范围内注册时,是否可以从Ninject提供程序中的容器中获取类型?

修改

如果用例看起来有点奇怪,我道歉,我正在尝试一些关于如何管理我的工作单元和其他服务/经理的想法,这些想法可能需要处理完成业务用例。我知道工作单位的共同点是#34;开始&#34;然后传递给可能需要参与更大进程的所有依赖项。我想我宁愿让我的管理员把一个工作单位带到工厂,以便它可以确定性地破坏UOW,并且很清楚用户的所有者是谁。提供给管理者/服务的内容将是工作单元的代理,在协调器启动实际工作单元之前,该工作单元将为空。这就是为什么我试图从我的提供商中已注册的类型链接代理的原因。这一点都是非常实验性的,并且正在测试一些想法。

我很高兴听到任何进一步的想法。

1 个答案:

答案 0 :(得分:0)

要让MethodThatGetsAnotherDependency()能够.Get<>()绑定.InNamedScope(...)的实例,您需要添加Context Preservation Extension

这是因为NamedScope正在向具有.DefinesNamedScope(...)的绑定的请求上下文添加参数。一旦该请求结束,该上下文及其参数就会被遗忘。现在使用ContextPreservation扩展,保留上下文并重新用于后期/工厂创建(Func<>,接口工厂与.ToFactory()绑定...)。它认为它也应该与提供商合作。 如果没有,只需切换到工厂而不是提供商。

然而,我不得不承认我并不完全明白为什么/你想要实现的目标。可能有更简单的方法。