In .NET framework, you can use Ninject to achieve contextual binding.
So for example:
Bind<IWarrior>().To<Samurai>().WhenInjectedInto(typeof(OnLandAttack));
Bind<IWarrior>().To<SpecialNinja>().WhenInjectedInto(typeof(AmphibiousAttack));
This means you can inject different concrete implementations depending on what you're injecting into.
I cannot see any method to achieve the same thing in .NET Core 2.2 - is this not possible, or does it just require a bunch of extra configuration?
Example code from the Ninject site
I had a need for something like this and ended up creating a NuGet package for it: https://www.nuget.org/packages/ServiceProviderContextualBinding/
Usage looks like this:
services.AddSingleton<IService, DefaultService>();
services.AddSingleton<ReplacementService>();
services.WithReplacement<IService, ReplacementService>()
.AddSingleton<Consumer>();
This package is basically a facade over the ActivatorUtilities.CreateInstance method, which is part of the MS DI code.
Related
I am currently migrating from .net4.6 which uses NInject modules. My target is to use .net6 core and its native DI. While doing so I came across a statement from NInject for which I am wondering if there is an equivalent for the same in .net6 native DI ?
this.Kernel.Bind(typeof(ICachePoolProvider<>)).To(typeof(CachePoolProvider<>));
Should I register for each type of ICachePoolProvider as shown below?
services.AddSingleton<ICachePoolProvider<string>,CachePoolProvider<string>);
services.AddSingleton<ICachePoolProvider<QueueClient>,CachePoolProvider<QueueClient>);
services.AddSingleton<ICachePoolProvider<NamespaceManager>,CachePoolProvider<NamespaceManager>);
I never used NInject but from your code I expect the method you are searching for is:
services.AddSingleton(typeof(ICachePoolProvider<>), typeof(CachePoolProvider<>));
You can find a good example of an IGenericRepository here
What is the correct way for a Libary to call an object that was injected through Dependency Inject?
Background: I have multiple .NET Core app that uses dependency injection for all major objects and uses libraries for reusability. It is working great. App1 calls Libary1 and Libary2. App2 calls Libary2 and Libary3 etc.
service.AddTransient<Libary1.ILibary1Dependency, Libary1.Libary1Dependency>();
service.AddTransient<Libary2.ILibary1Dependency, Libary2.Libary1Dependency>();
service.AddTransient<Libary2.ILibary2Dependency, Libary2.Libary2Dependency>();
service.AddTransient<Libary3.ILibary1Dependency, Libary3.Libary1Dependency>();
Now in Libary2.ILibary1Dependency there is a method that needs to call a new Libary2.ILibary2Dependency. What is the best way to do this?
Should I just do a new Libary2.ILibary2Dependency(property1, property2...);?
Is it ok in the main app to actually inject the IServiceCollection object and then in the constructor of the Libary2.ILibary1Dependency get the IServiceCollection?
Is there some nugget package that I don't know about that fixes this perfectly?
Note: Libary2.ILibary2Dependency does get called on its own via dependency injection, if you were wondering
As suggested in the comments, keep the libraries independent of the Service Dependency Injection. And let the Caller make the decision to inject them on need basis and it helps to keep the libraries independent of IOC Framework.
If you need to change the IOC Framework or even upgrade to latest versions, you probably need to spend time to update across the libraries, the more these dependencies you have the more house cleaning needed eventually.
I have seen people creating generic wrappers to avoid having specific dependencies on IOC Frameworks, but its kind of overkill.
If all you have is a 3 or 4 projects, it doesn't matter to refactor them away in both directions.
I'm configuring DI container to be able to resolve several services inside my app.
If I would have used autofac, I would use modules from there to logically bundle registrations.
Does ASP.NET core framework has analogues for modules? How can I achieve that if I want?
Official doc on DI says:
Does that mean that I shouldn't be looking for module system anymore?
And if I have like 20-50 services, it's best to create an extension for each separate one?
AFAIK there is nothing comparable to autofac's modules registration in the core DI implementations.
You would have to implement it on your own, which should not become a really big deal.
A would like to make my ASP.NET Core project could see only another library: Api, where I have interfaces. And another library makes wiring for interfaces and their implementation.
Instead of it Microsoft Dependency Injection Library proposes to make a wiring point right in the asp.net project. In this case this project will see both libraries: Api and ApiImpl. And it's not acceptable.
I wanna find a solution like Ninject, for example, does with modules.
A kind solution of this is here:
https://github.com/aspnet/DependencyInjection/issues/497
I understand some of the functionality of Ninject and have been able to use it for IoC.
When I go to add a reference to Ninject to a project in VS2010, using NuGet, I see other Ninject extensions in the list. Specifically Ninject.MVC3. Also on the Ninject website under extensions ( http://www.ninject.org/extensions.html ) I see Ninject.Web.Mvc.
If I am creating MVC3 applications do I need to use this extension of Ninject? Does my basic use of Ninject for IoC with classes/interfaces require anything beyond the standard library?
What is the difference between Ninject and Ninject.MVC3/Ninject.Web.Mvc in an MVC3 project?
ninject.web.mvc is a ninject (core) complement for the ASP MVC (3) applications. Basically - you should use it, when you want to use Ninject in an ASP MVC project.
From the documentation:
This extension allows integration between the Ninject core and ASP.NET
MVC projects. To use it, just make your HttpApplication (typically in
Global.asax.cs) extend NinjectHttpApplication:
MVC 3 extension contains the crucial methods to wire up the DI composition root into MVC application - it means that Ninject will be responsible for instantiating your controllers, that has dependencies on other components (Ninjects 'overrides' the use of DefaultControllerFactory which is only able to create controllers with parameterless constructors).
In the documentation there are mentioned two methods, how to do it: either extending the NinjectHttpApliaction in global.asax or using the NinjectWebCommon class inside the App_Start folder.
There is also ninject.web.common extension, which is required for ninject.web.mvc. It contains e.g. the definition of InRequestScope.