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

Question

我一直在研究与硬件抽象相关的依赖注入。所以，基本上我有一些我想从 C# 应用程序中控制的硬件设备。这些设备通常有一个根设备，用于访问叶子设备。结构很简单：LeafDevice1 & 2通过Interface1连接到RootDevice1，LeafDevice3连接到RootDevice2等等。

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

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

据我了解，当您想指定将注入哪个实现时，使用 IOC 容器最有意义。但据我所知，我正在使用容器来管理在何处使用哪个特定对象。当然，上述对象的实际实现可能有所不同，但它更像是一个 "what is used where?" 而不是 "which implementation is used" 问题。

构建一个我可以用来访问我的设备的类似设备树的东西不是更好吗？

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 提供了多个 BusMasters，可用于与所述叶设备进行通信。

提前致谢

Answer 1

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

不重新发明轮子，不重复两个都满意就好了。

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

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

Using Dependency Injection for hardware abstraction

c#

dependency-injection

hardware-programming