Dependency Injection for Implementations

[grahamehorner]

Please consider a lightweight IoC/DependencyInjection for driver implementations, ie DeviceDriverCollection.Add(options =>{ ... }); similar to the IServiceCollection so that a developer may register driver implementation base on custom logic and allow injection of the implementation into the constructor of the driver consumer(s)

[joperezr]

I'm not sure I understand what would be the advantages of having this. Would you mind providing an Api proposal that would have more details and samples into how this would be used? Here is an example of a good Api Proposal: https://github.com/dotnet/corefx/issues/271

[joshfree]

@grahamehorner for layering reasons, we're currently not planning to take a dependency on the higher level Microsoft.Extensions.DependencyInjection assembly from this low level hardware abstraction. However, with the current API you can specify a custom device driver by inheriting from the GpioDriver abstract class and passing it as a parameter to the GpioController ctor.

Does this satisfy the needs of your scenario?

https://github.com/dotnet/iot/blob/master/src/System.Device.Gpio/System/Device/Gpio/GpioDriver.cs
https://github.com/dotnet/iot/blob/master/src/System.Device.Gpio/System/Device/Gpio/GpioController.cs#L39

        using (GpioController controller = new GpioController(myNumberingScheme, myCustomGpioDriver))
        {
            controller.OpenPin(pin, PinMode.Output);

[grahamehorner]

@joshfree while I understand not wishing to take a dependency on a higher level assembly; I do believe the that driver abstraction/implementations should be held in some kind of registry and/or a simple DI system; this would allow greater flexibility/testability for developers with minimal code change; swapping drivers by way of change the registration/configuration and not code.

eg. the registration of an the implementation of VirtualGpioDriver, the options type associated with the driver options and an optional action to perform additional configure of the driver at runtime construction/instantiation.

System.Device.DriverRegistry.Register<TDriver,TDriverOptions>(string driverName, Action<TDriverOptions> options)

using(var driver = System.Device.DriverRegistry.Resolve<GpioDriver>("driverName",(options)=>
{ 
options.someConfiguration = 12;
}))
{
driver.doSomeWork();
}

[krwq]

[Triage] This seems to bit a bit out of scope of this project. It adds too much overhead for most common scenarios. If we want to have something like that it should be an additional package.