是否有可能和/或一个好主意使用Ninject(或任何其他 IoC 容器,就此而言)为不存在适当实现的情况创建默认绑定ActivationException
,并使用此默认绑定而不是必须处理当存在多个绑定或特定请求不存在绑定时?
我一直在使用 Ninject 的Factory和Conventions扩展项目,但我想知道它们是否掩盖了我在更基本的层面上犯的错误,所以我创建了一个测试来说明我想要做什么,如尽我所能:
鉴于以下情况:
public interface IWidget { }
public class DefaultWidget : IWidget { }
public class BlueWidget : IWidget { }
以及以下使用FluentAssertions的xUnit测试:
[Fact]
public void Unknown_Type_Names_Resolve_To_A_Default_Type()
{
StandardKernel kernel = new StandardKernel();
// intention: resolve a `DefaultWidget` implementation whenever the
// 'name' parameter does not match the name of any other bound implementation
kernel.Bind<IWidget>().To<DefaultWidget>();
kernel.Bind<IWidget>().To<BlueWidget>().Named(typeof(BlueWidget).Name);
kernel.Get<IWidget>("RedWidget").Should().BeOfType<DefaultWidget>();
// ACTIVATION EXCEPTION (**NO matching bindings available** for `IWidget`)
}
我不确定沿着这条路走下去,如果可能的话,会导致我对 Service Locator 模式的一个令人讨厌的实现,除了这似乎是那些回答过类似问题的人给出的警告。
那么,这是滥用/误用IoC 容器来做我要求它做的事情吗?
对于我拥有的所有显式类型,我似乎应该想用 IoC 绑定/解析类型,所以这部分对我来说似乎没有错。在现实生活中,会有更多明确的绑定,例如BlueWidget
,以及传入的“RedWidget”字符串值的未知数量的变体。
一般来说,某些接口的默认实现的概念似乎并不常见,那么如果不在 IoC 容器的范围内,这种解决请求的机制会在哪里呢?
我还计划使用工厂模式来创建IWidget
实现。到目前为止,我一直在使用由 Ninject.Extensions.Factory 自动创建的工厂以及自定义实例提供程序和自定义绑定生成器,但我无法解决这个问题。
对工厂实现有更多的控制(换句话说,使用我自己的工厂,而不是来自 Ninject.Extensions.Factory 的自动工厂)有帮助吗?过去,我使用 Assembly 反射来查找候选类型,并使用 Activation.CreateInstance() 来创建我需要的特定实现或默认实现,但是一旦这些实现具有自己的构造函数注入依赖项,这将变得非常麻烦因为依赖注入原则应用于这些实现。因此,我转向 IoC 容器寻求解决方案——但这并没有像我希望的那样奏效。
更新 1 -- 使用我自己的工厂实现成功
我对此不太满意,因为每次IWidget
必须编写新的实现时,我都必须打开这个工厂并更新它。在我的示例中,我还必须在绑定中添加另一行 - 但这就是基于约定的绑定的用武之地,我计划使用它来避免必须不断更新绑定定义。
使用这个工厂实现,
public interface IWidgetFactory { IWidget Create(string name); }
public class WidgetFactory : IWidgetFactory
{
private readonly IKernel kernel;
public WidgetFactory(IKernel kernel) { this.kernel = kernel; }
public IWidget Create(string name)
{
switch (name)
{
case "Blue":
return this.kernel.Get<IWidget>(typeof (BlueWidget).Name);
default:
return this.kernel.Get<IWidget>(typeof (DefaultWidget).Name);
}
}
}
我可以让这个测试通过:
[Fact]
public void WidgetBuilders_And_Customizers_And_Bindings_Oh_My()
{
StandardKernel kernel = new StandardKernel();
kernel.Bind<IWidget>().To<DefaultWidget>().Named(typeof(DefaultWidget).Name);
kernel.Bind<IWidget>().To<BlueWidget>().Named(typeof (BlueWidget).Name);
kernel.Bind<IWidgetFactory>().To<WidgetFactory>().InSingletonScope();
kernel.Get<IWidgetFactory>().Create("Blue")
.Should().BeOfType<BlueWidget>();
kernel.Get<IWidgetFactory>().Create("Red")
.Should().BeOfType<DefaultWidget>();
}
它有效,但感觉不对,原因如下:
- 我必须
IKernel
注入IWidgetFactory
- 对于 的每个新实现
IWidget
,IWidgetFactory
必须更新 - 似乎应该已经为此场景创建了一个 Ninject 扩展
更新结束 1
在这种情况下你会怎么做,考虑到IWidget
实现的数量很高,“小部件名称”参数的预期范围基本上是无限的,并且所有无法解析的小部件名称都应该使用DefaultWidget
?
您无需进一步阅读,但如果您有兴趣,以下是我在解决此问题时尝试的各种测试:
这是我经历的测试的完整演变:
[Fact]
public void Unknown_Type_Names_Resolve_To_A_Default_Type()
{
StandardKernel kernel = new StandardKernel();
// evolution #1: simple as possible
// PASSES (as you would expect)
//kernel.Bind<IWidget>().To<BlueWidget>();
//kernel.Get<IWidget>().Should().BeOfType<BlueWidget>();
// evolution #2: make the only binding to a different IWidget
// FAILS (as you would expect)
//kernel.Bind<IWidget>().To<DefaultWidget>();
//kernel.Get<IWidget>().Should().BeOfType<BlueWidget>();
// evolution #3: add the binding to `BlueWidget` back
// ACTIVATION EXCEPTION (more than one binding for `IWidget`)
//kernel.Bind<IWidget>().To<DefaultWidget>();
//kernel.Bind<IWidget>().To<BlueWidget>();
//kernel.Get<IWidget>().Should().BeOfType<BlueWidget>();
// evolution #4: make `BlueWidget` binding a *named binding*
// ACTIVATION EXCEPTION (more than one binding for `IWidget`)
//kernel.Bind<IWidget>().To<DefaultWidget>();
//kernel.Bind<IWidget>().To<BlueWidget>().Named(typeof (BlueWidget).Name);
//kernel.Get<IWidget>().Should().BeOfType<BlueWidget>();
// evolution #5: change `Get<>` request to specifiy widget name
// PASSES (yee-haw!)
//kernel.Bind<IWidget>().To<DefaultWidget>();
//kernel.Bind<IWidget>().To<BlueWidget>().Named(typeof(BlueWidget).Name);
//kernel.Get<IWidget>("BlueWidget").Should().BeOfType<BlueWidget>();
// evolution #6: make `BlueWidget` binding *non-named*
// ACTIVATION EXCEPTION (**NO matching bindings available** for `IWidget`)
//kernel.Bind<IWidget>().To<DefaultWidget>();
//kernel.Bind<IWidget>().To<BlueWidget>();
//kernel.Get<IWidget>("BlueWidget").Should().BeOfType<BlueWidget>();
// evolution #7: ask for non-existance `RedWidget`, hope for `DefaultWidget`
// ACTIVATION EXCEPTION (**NO matching bindings available** for `IWidget`)
//kernel.Bind<IWidget>().To<DefaultWidget>();
//kernel.Bind<IWidget>().To<BlueWidget>();
//kernel.Get<IWidget>("RedWidget").Should().BeOfType<DefaultWidget>();
// evolution #8: make `BlueWidget` binding a *named binding* again
// ACTIVATION EXCEPTION (**NO matching bindings available** for `IWidget`)
//kernel.Bind<IWidget>().To<DefaultWidget>();
//kernel.Bind<IWidget>().To<BlueWidget>().Named(typeof(BlueWidget).Name);
//kernel.Get<IWidget>("RedWidget").Should().BeOfType<DefaultWidget>();
// evolution #9: remove `RedWidget` specification in Get<> request
// ACTIVATION EXCEPTION (back to **more than one** binding for `IWidget`)
//kernel.Bind<IWidget>().To<DefaultWidget>();
//kernel.Bind<IWidget>().To<BlueWidget>().Named(typeof(BlueWidget).Name);
//kernel.Get<IWidget>().Should().BeOfType<DefaultWidget>();
}