Question

我一直在使用与硬件抽象相关的依赖注入。所以，基本上我有一些我想在C＃应用程序中控制的硬件设备。这些设备通常具有用于访问叶子设备的根设备。结构非常简单：LeafDevice1＆amp; 2通过Interface1连接到RootDevice1，LeafDevice3连接到RootDevice2，依此类推。

现在我认为我可以通过依赖注入来解决这个问题，因为“leaf”设备通常不关心它们是如何连接的，只要它们连接到指定的接口即可。但我想知道使用IOC容器的依赖注入是否真的是最好的方法。我怀疑的主要原因是：我一直使用命名依赖项。如果我将设备B和C连接到根设备A，我想确保它们指的是完全相同的设备。此外，我使用了很多单例范围，因为命名的依赖xyz应该只存在一次。

因此，在我的情况下，配置容器意味着将许多命名依赖项粘合在一起。

据我了解，当您想要指定将注入哪个实现时，使用IOC容器最有意义。但据我所知，我正在使用容器来管理在哪里使用哪个特定对象。当然，所述对象的实际实现可以是不同的，但它仍然更像是“在哪里使用的？”不是“使用哪种实施”问题。

构建像我可以用来访问设备的设备树这样的东西不是更好吗？

Bind<RootDevice>().ToConstructor<RootDevice>(e => new RootDevice(serialNumber))
    .InSingletonScope().Named("ConcreteRootDevice");

Bind<IBusMaster>().ToMethod<IBusMaster>(e => e.Kernel.Get<RootDevice>("ConcreteRootDevice")
    .GetBusMaster(0)).Named("ConcreteBus1");

Bind<IBusMaster>().ToMethod<IBusMaster>(e => e.Kernel.Get<RootDevice>("ConcreteRootDevice")
    .GetBusMaster(1)).Named("ConcreteBus2");

Bind<IBusMaster>().ToMethod<IBusMaster>(e => e.Kernel.Get<RootDevice>("ConcreteRootDevice")
    .GetBusMaster(2)).Named("ConcreteBus3");
Bind<IBusMaster>().ToMethod<IBusMaster>(e => e.Kernel.Get<RootDevice>("ConcreteRootDevice")
    .GetBusMaster(3)).Named("ConcreteBus4");

Bind<LeafDevice>().ToConstructor<LeafDevice>(o =>
    new LeafDevice(o.Context.Kernel.Get<IBusInterface>("ConcreteBus1")))
        .Named("ConcreteLeafDevice1");

Bind<LeafDevice>().ToConstructor<LeafDevice>(o =>
    new LeafDevice(o.Context.Kernel.Get<IBusInterface>("ConcreteBus1")))
        .Named("ConcreteLeafDevice2");

Bind<LeafDevice>().ToConstructor<LeafDevice>(o =>
    new LeafDevice(o.Context.Kernel.Get<IBusInterface>("ConcreteBus2")))
        .Named("ConcreteLeafDevice3");

在此示例中，LeafDevices将依赖于抽象IBusInterface与实际硬件设备进行通信。 Root Device提供了几个BusMaster，可用于与所述叶子设备进行通信。

提前致谢

Answer 1

根据我的经验，如果您在应用程序中大量使用单例和/或轻量级模式，则仅使用DI容器来创建单例范围的实例是值得的。

不要重新发明方向盘，而不要重复两者都满意。

唯一的考虑因素是表现。如果使用符合性能规格/期望的DI容器，请使用它！它们经过了良好的测试，更加专业和稳定，您可以从头开始编写。

使用依赖注入进行硬件抽象

1 个答案: