Develop Reference

Having some parameters Injected with DI and some assigned manually

In a .NET Core 3.1 console application I want a Class that would have some parameters in constructor injected but some that I could assign manually. For example something like that but with IConfiguration Injected:
static void Main() {
var myObj1 = new MyClass(1);
var myObj2 = new MyClass(2);
}
public class MyClass {
public MyClass(IConfiguraiton config, int myVal)
{
}
}
I tried this with Ninject:
static void Main()
{
kernel = new StandardKernel();
kernel.Load(Assembly.GetExecutingAssembly());
kernel.Get<MyClass>();
}
public class MyClass
{
public MyClass(IConfiguraiton config)
{
}
}
public class Bindings : NinjectModule
{
public override void Load()
{
var configuration = new ConfigurationBuilder().AddJsonFile($"appsettings.json").Build();
Bind<IConfiguration>().ToMethod(ctx => SetupConfiguration()).InSingletonScope();
Bind<MyClass>().ToSelf().InTransientScope();
}
}
I managed to make simple dependency injection, but haven't had any success making injection with parameters.
I've read a lot of people suggesting that it's better to pass parameters into methods of the class rather than constructor, however in my situation this isn't an option in addition I'm a software engineering student, and would like to learn how to do this, since it might be useful in some situations.

This is a situation where the Ninject.Extensions.Factory is useful, as it is made exactly for this situation. It does pull in the Factory dependency in addition to Castle.Core, as it uses DynamicProxy under the hood (as a SE student, playing with this library is a good idea for using the interceptor pattern).
To use it, you define a Factory interface like so:
public interface IMyClassFactory
{
MyClass Create(int myVal);
}
Note that the Create method returns MyClass, and the argument(s) to the Create method match exactly in type and name to the arguments you wish to provide. The argument type(s) you want injected must be registered with the kernel. Unfortunately, it is easy to make a mistake here - if you specify a parameter that does not exist in the factory interface it is ignored, but if you forget one it will throw an exception when called.
Next, register IMyClassFactory like this: Bind<IMyClassFactory>().ToFactory(); and remove your binding for MyClass. Then wherever you need to create an instance, inject IMyClassFactory and call Create: kernel.Get<IMyClassFactory>().Create(2)
You can achieve the same result without using Ninject.Extensions.Factory by writing and registering your own implementation of IMyClassFactory, essentially doing the same thing that the code the Factory extension ends up emitting. A full sample is below using both methods based on commenting in/out the registration (note the output if you add .InSingletonScope() to the registration of IConfiguraiton - both approaches respect the binding scopes of Ninject).
internal class Program
{
static void Main(string[] args)
{
var kernel = new StandardKernel();
kernel.Bind<IConfiguraiton>().To<Configuraiton>();
kernel.Bind<IMyClassFactory>().ToFactory();
//kernel.Bind<IMyClassFactory>().To<NinjectMyClassFactory>().InSingletonScope();
var factory = kernel.Get<IMyClassFactory>();
var one = factory.Create(1);
var two = factory.Create(2);
}
}
public interface IMyClassFactory
{
MyClass Create(int myVal);
}
public class NinjectMyClassFactory : IMyClassFactory
{
public NinjectMyClassFactory(IResolutionRoot resolutionRoot)
{
ResolutionRoot = resolutionRoot;
}
private IResolutionRoot ResolutionRoot { get; }
public MyClass Create(int myVal)
{
return ResolutionRoot.Get<MyClass>(new ConstructorArgument("myVal", myVal));
}
}
public class MyClass
{
public MyClass(IConfiguraiton config, int myVal)
{
Console.Out.WriteLine("Created MyClass({0},{1})", config.MyNum, myVal);
}
}
public interface IConfiguraiton { int MyNum { get; } }
public class Configuraiton : IConfiguraiton
{
static int CreateCount;
public Configuraiton()
{
MyNum = Interlocked.Increment(ref CreateCount);
}
public int MyNum { get; }
}

Passing a reference type to generic method with Unity

Ok this is driving me crazy! I have a generic method in a generic class.
public interface IHandler<T> where T : class
{
T[] parseCSV(string InputFileName)
}
public class Handler<T> : IHandler<T> where T : class
{
public T[] parseCSV(string InputFileName)
{
if (File.Exists(InputFileName))
{
_inputFileName = InputFileName;
var Engine = new FileHelperEngine<T>();
return Engine.ReadFile(_inputFileName);
}
else
{
throw new IOException($"{InputFileName} not found!");
}
}
}
I have registered the generic in a IoC container as such:
container.RegisterType(typeof(IHandler<>), typeof(Handler<>));
Along with several mappers to parse files with the FileHelpers package
container.RegisterType<IMapper1, Mapper1>();
container.RegisterType<IMapper2, Mapper2>();
container.RegisterType<IMapper3, Mapper3>();
My container is legit for the majority of my app, and I can instate the IHandler object.
IHandler<IMapper1> Handler1 = container.Resolve<IHandler<IMapper1>>();
However, I cannot figure out how to pass the IMapper1 object into the generic parseCSV method so it will resolve in FileHelperEngine.
Does anyone know how to pass the Mapper object to FileHelperEngine using Unity? I would like to get that dependency off of the client code.

You have a dependency in your parseCSV method. Therefore, you should inject that into your class as well. There are many ways to do that but I prefer, and I have seen many other devs also prefer, constructor injection.
Thus all you need is an interface and then inject an instance of a class which implements the interface into your constructor like this:
public interface IFileHelperEngine<T> where T : class
{
T[] ReadFile(string inputFileName);
}
public class Handler<T> : IHandler<T> where T : class
{
private IFileHelperEngine<T> fileHelperEngine;
public Handler(IFileHelperEngine<T> fileHelperEngine) //<----See this.
{
this.fileHelperEngine = fileHelperEngine;
}
public T[] parseCSV(string InputFileName)
{
if (File.Exists(InputFileName))
{
_inputFileName = InputFileName;
return this.fileHelperEngine.ReadFile(_inputFileName); //<--and this
}
throw new IOException($"{InputFileName} not found!");
}
}
This is actually good because now you can mock the IFileHelperEngine when you are unit testing the Handler<T> class.
FYI, you are not using .NET naming conventions; Locals should use camel case notation and method names should use Pascal Notation.

Ninject - Bind different interfaces implementations to the same class

I'm new to DI (using Ninject) and just started to learn the concepts, but I've been scratching my head for a while to understand this:
Suppose I have DIFFERENT usage of the same class in my program (ProcessContext in the example below).
In the first class (SomeClass) : I would like to inject Implement1 to ProcessContext instance.
In the second class (SomeOtherClass) : I would like to inject Implement2 to ProcessContext instance.
How should I perform the bindings using Ninject ?
public class Implement1 : IAmInterace
{
public void Method()
{
}
}
public class Implement2 : IAmInterace
{
public void Method()
{
}
}
public class ProcessContext : IProcessContext
{
IAmInterface iamInterface;
public ProcessContext(IAmInterface iamInterface)
{
this.iamInterface = iamInterface;
}
}
public class SomeClass : ISomeClass
{
public void SomeMethod()
{
// HERE I WANT TO USE: processcontext instance with Implement1
IProcessContext pc = kernel.Get<IProcessContext>();
}
}
public class SomeOtherClass : ISomeOtherClass
{
public void SomeMethod()
{
// HERE I WANT TO USE: processcontext instance with Implement2
IProcessContext pc = kernel.Get<IProcessContext>();
}
}

You could use named bindings for this.
e.g. something like:
Bind<IProcessContext>()
.To<ProcessContext>()
.WithConstructorArgument("iamInterface", context => Kernel.Get<Implement1>())
.Named("Imp1");
Bind<IProcessContext>()
.To<ProcessContext>()
.WithConstructorArgument("iamInterface", context => Kernel.Get<Implement2>())
.Named("Imp2");
kernel.Get<IProcessContext>("Imp1");

You can inject additional constructor parameters easily in this way:
public void SomeMethod()
{
var foo = new Ninject.Parameters.ConstructorArgument("iamInterface", new Implement2());
IProcessContext pc = kernel.Get<IProcessContext>(foo);
}
For now, I don't have access to ninject. So tell me if it doesn't work as expected.

This is not possible as Ninject has no way of knowing which implementation to return. However; if you create a new instance of your IProcessContext by passing in a variable then Ninject will look for the implementation with the appropriate constructor and return that one.

Ninject Contextual Binding at runtime depending on a specific value [duplicate]

If I have the following code:
public class RobotNavigationService : IRobotNavigationService {
public RobotNavigationService(IRobotFactory robotFactory) {
//...
}
}
public class RobotFactory : IRobotFactory {
public IRobot Create(string nameOfRobot) {
if (name == "Maximilian") {
return new KillerRobot();
} else {
return new StandardRobot();
}
}
}
My question is what is the proper way to do Inversion of Control here? I don't want to add the KillerRobot and StandardRobot concretes to the Factory class do I? And I don't want to bring them in via a IoC.Get<> right? bc that would be Service Location not true IoC right? Is there a better way to approach the problem of switching the concrete at runtime?

For your sample, you have a perfectly fine factory implementation and I wouldn't change anything.
However, I suspect that your KillerRobot and StandardRobot classes actually have dependencies of their own. I agree that you don't want to expose your IoC container to the RobotFactory.
One option is to use the ninject factory extension:
https://github.com/ninject/ninject.extensions.factory/wiki
It gives you two ways to inject factories - by interface, and by injecting a Func which returns an IRobot (or whatever).
Sample for interface based factory creation: https://github.com/ninject/ninject.extensions.factory/wiki/Factory-interface
Sample for func based: https://github.com/ninject/ninject.extensions.factory/wiki/Func
If you wanted, you could also do it by binding a func in your IoC Initialization code. Something like:
var factoryMethod = new Func<string, IRobot>(nameOfRobot =>
{
if (nameOfRobot == "Maximilian")
{
return _ninjectKernel.Get<KillerRobot>();
}
else
{
return _ninjectKernel.Get<StandardRobot>();
}
});
_ninjectKernel.Bind<Func<string, IRobot>>().ToConstant(factoryMethod);
Your navigation service could then look like:
public class RobotNavigationService
{
public RobotNavigationService(Func<string, IRobot> robotFactory)
{
var killer = robotFactory("Maximilian");
var standard = robotFactory("");
}
}
Of course, the problem with this approach is that you're writing factory methods right inside your IoC Initialization - perhaps not the best tradeoff...
The factory extension attempts to solve this by giving you several convention-based approaches - thus allowing you to retain normal DI chaining with the addition of context-sensitive dependencies.

The way you should do:
kernel.Bind<IRobot>().To<KillingRobot>("maximilliam");
kernel.Bind<IRobot>().To<StandardRobot>("standard");
kernel.Bind<IRobotFactory>().ToFactory();
public interface IRobotFactory
{
IRobot Create(string name);
}
But this way I think you lose the null name, so when calling IRobotFactory.Create you must ensure the correct name is sent via parameter.
When using ToFactory() in interface binding, all it does is create a proxy using Castle (or dynamic proxy) that receives an IResolutionRoot and calls the Get().

I don't want to add the KillerRobot and StandardRobot concretes to the Factory class do I?
I would suggest that you probably do. What would the purpose of a factory be if not to instantiate concrete objects? I think I can see where you're coming from - if IRobot describes a contract, shouldn't the injection container be responsible for creating it? Isn't that what containers are for?
Perhaps. However, returning concrete factories responsible for newing objects seems to be a pretty standard pattern in the IoC world. I don't think it's against the principle to have a concrete factory doing some actual work.

I was looking for a way to clean up a massive switch statement that returned a C# class to do some work (code smell here).
I didn't want to explicitly map each interface to its concrete implementation in the ninject module (essentially a mimic of lengthy switch case, but in a diff file) so I setup the module to bind all the interfaces automatically:
public class FactoryModule: NinjectModule
{
public override void Load()
{
Kernel.Bind(x => x.FromThisAssembly()
.IncludingNonPublicTypes()
.SelectAllClasses()
.InNamespaceOf<FactoryModule>()
.BindAllInterfaces()
.Configure(b => b.InSingletonScope()));
}
}
Then create the factory class, implementing the StandardKernal which will Get the specified interfaces and their implementations via a singleton instance using an IKernal:
public class CarFactoryKernel : StandardKernel, ICarFactoryKernel{
public static readonly ICarFactoryKernel _instance = new CarFactoryKernel();
public static ICarFactoryKernel Instance { get => _instance; }
private CarFactoryKernel()
{
var carFactoryModeule = new List<INinjectModule> { new FactoryModule() };
Load(carFactoryModeule);
}
public ICar GetCarFromFactory(string name)
{
var cars = this.GetAll<ICar>();
foreach (var car in cars)
{
if (car.CarModel == name)
{
return car;
}
}
return null;
}
}
public interface ICarFactoryKernel : IKernel
{
ICar GetCarFromFactory(string name);
}
Then your StandardKernel implementation can get at any interface by the identifier of you choice on the interface decorating your class.
e.g.:
public interface ICar
{
string CarModel { get; }
string Drive { get; }
string Reverse { get; }
}
public class Lamborghini : ICar
{
private string _carmodel;
public string CarModel { get => _carmodel; }
public string Drive => "Drive the Lamborghini forward!";
public string Reverse => "Drive the Lamborghini backward!";
public Lamborghini()
{
_carmodel = "Lamborghini";
}
}
Usage:
[Test]
public void TestDependencyInjection()
{
var ferrari = CarFactoryKernel.Instance.GetCarFromFactory("Ferrari");
Assert.That(ferrari, Is.Not.Null);
Assert.That(ferrari, Is.Not.Null.And.InstanceOf(typeof(Ferrari)));
Assert.AreEqual("Drive the Ferrari forward!", ferrari.Drive);
Assert.AreEqual("Drive the Ferrari backward!", ferrari.Reverse);
var lambo = CarFactoryKernel.Instance.GetCarFromFactory("Lamborghini");
Assert.That(lambo, Is.Not.Null);
Assert.That(lambo, Is.Not.Null.And.InstanceOf(typeof(Lamborghini)));
Assert.AreEqual("Drive the Lamborghini forward!", lambo.Drive);
Assert.AreEqual("Drive the Lamborghini backward!", lambo.Reverse);
}

In which library should an abstract factory interface and an actual factory be defined?

Short question
Where should I put the abstract factory interface and the actual factory?
Overview
I'm writing a simple video transcoding application and I'm trying to wrap my head around dependency injection.
I have separated my application into several projects in visual studio.
One class library for the transcoder, used by the application engine
One class library for the application engine that will be used by a gui or console interface
One console application that will be the main user interface for now
Without DI
This is what everything looks like before dependency injection
The transcoder lib:
namespace SimpleFFmpeg {
public interface ITranscoder {
void Transcode(String fileName);
}
public class Transcoder:ITranscoder {
// ...
public void Transcode(String fileName) {
// do transcoding stuff
}
// ...
}
}
The PusherEngine lib:
using SimpleFFmpeg;
namespace PusherLib {
public class PusherEngine {
private readonly List<VideoItem> _items;
public PusherEngine() {
_items = new List<VideoItem>();
}
// ...
public void processItems() {
foreach (VideoItem item in _items) {
ITranscoder t = new Transcoder();
t.Transcode(item.FileName);
}
}
// ...
}
}
The actual application:
namespace Pusher {
class Program {
static void Main(string[] args) {
PusherEngine pe = new PusherEngine();
pe.addVideoItem(new VideoItem(...));
pe.processItems();
}
}
}
Refactor to use DI
I create a generic abstract factory interface, like suggested in this question: Creating new instances while still using Dependency Injection
public interface IFactory<T> {
T Get();
}
Next I create a factory that creates ITranscoders
public class TranscoderFactory: IFactory<ITranscoder> {
public ITranscoder Get() {
return new SimpleFFmpeg.Transcoder();
}
}
Then I modify the PusherEngine to require a factory dependence in the constructor:
using SimpleFFmpeg;
namespace PusherLib {
public class PusherEngine {
private readonly IFactory<ITranscoder> _transcoderFactory;
private readonly List<VideoItem> _items;
public PusherEngine(IFactory<ITranscoder> transcoderFactory) {
_items = new List<VideoItem>();
_transcoderFactory = transcoderFactory;
}
// ...
public void processItems() {
foreach (VideoItem item in _items) {
ITranscoder t = _transcoderFactory.Get();
t.Transcode(item.FileName);
}
}
// ...
}
}
Finally, in the Program it looks like this:
namespace Pusher {
class Program {
static void Main(string[] args) {
IFactory<ITranscoder> f = new TranscoderFactory();
PusherEngine pe = new PusherEngine(f);
pe.addVideoItem(new VideoItem(...));
pe.processItems();
}
}
}
Question
In which lib/project should the IFactory interface be defined?
In which lib/project should the TranscoderFactory be defined?
Do they live in the Transcoder lib? In the PusherLib? Or in the actual frontend application?
I'm looking for best practices.
Thanks!

In my opinion, it doesn't matter. For me, the main point of dependency injection is being able to inject something other than the real implementation while testing. I keep my unit tests in a separate project along with the various mock definitions used for testing. The real implementations as well as the 'abstract' logic are all kept in the same assembly/project/namespace.

If you really need a factory (see comment), then this blog post by Mark Seemann addresses this issue.
Briefly, if you use the IoC Container in your factory, you want to use it in the composition root. If not, there is no harm for it to remain in the same assembly as the class it is instantiating.
EDIT
For your particular case, you do not need a factory, since you already have everything you need to solve this dependency.
using SimpleFFmpeg;
namespace PusherLib {
public class PusherEngine {
private readonly ITranscoder _transcoder;
private readonly List<VideoItem> _items;
public PusherEngine(ITranscoder transcoder) {
_items = new List<VideoItem>();
_transcoder = transcoder;
}
// ...
public void processItems() {
foreach (VideoItem item in _items) {
_transcoder.Transcode(item.FileName);
}
}
// ...
}
}
The initialization would then look like this:
namespace Pusher {
class Program {
static void Main(string[] args) {
ITranscoder t = new Transcoder();
PusherEngine pe = new PusherEngine(t);
pe.addVideoItem(new VideoItem(...));
pe.processItems();
}
}
}
The reason why a factory was needed in the answer you linked is that the dependency needed values only known at run-time to be able to be instantiated, while your dependency does not require run-time dependent arguments to be created.

To answer your actual question, and not if this is a good use case for a factory or not:
For this purpose I sometimes split up Interface and Implementation into different projects, and something like your IFactory<> would live in the Common.I project.
This doesn't work in every scenario, but one of the advantages of this approach for me is that I can swap out Implementation dll's with either mocks or a new implementation when there are underlying technology changes.
For example, we recently switched from parsing xml files from a directory to getting data from a service. The only thing I had to update on client machines was this one Implementation dll because the interface did not change at all.
But I guess in the end it doesn't really matter, as mentioned before.