Is it right at all to "wrap" a StandardKernel with the required NinjectModules in a static class in a separate, shared library, and use that same library whenever injection is needed (instead of instantiating a new kernel everytime)?
Edit: I am trying to use Ninject from within the WCF service I am developing at the moment.
(Please bear with me if what I am saying is completely rubish since I just started learning about DI and IoC containers)
See https://github.com/ninject/ninject.extensions.wcf . This extension will create the WCF service using the Ninject kernel. That way you can use constructor injection instead of using the Service Locator pattern.
Related
I have the following code snippet in my application:
services.AddScoped<IMyInterface, MyService>();
services.AddSingleton<IYourInterface, YourService>();
Due to some environment initialization process, I have to be able to obtain the singleton instance of IYourInterface within Startup class to call the service to read a couple of configuration entries from a remote server and populate them. How can I achieve this goal considering the fact that I am using .Net Core's built-in DI framework?
The way to do this to create this instance manually up front as follows:
var service = new YourService();
services.AddScoped<IMyInterface, MyService>();
services.AddSingleton<YourService>(service);
Just as it is wise to separate the registration process from use (as the Microsoft.Extensions.DependencyInjection library correctly forces), this kind of separation is important between loading/building configuration and making the container registrations. Doing register-resolve-register is unsupported by libraries like MS DI, Autofac and Simple Injector, because it can lead to lots of complexity and subtle bugs.
My application uses autofac IoC. It contains a layer that establishes connections to external applications (creating "Protocol" objects) - Therefore, I realized from my previous question that I should use autofac factory:
Autofac resolve in deep layer
I have a side project that includes all the autofac nugets and dlls. This one provides specific API which I use to register types in my application:
RegisterType
RegisterTypeAndAutowireProperties
RegisterConfigurationObject
RegisterInstance
BuildContainer
UpdateContainer
I believe this API is generic and fits for any application that will want to make use of IoC container.
My problem is with the factories. For example in my current application I need a factory for protocols (which are keyed and depend on many keyed services as well). Each protocol object is taking different kind and number of services and therefore I don't have a way other than making an explicit method for each protocol registration if I'm correct.
Now what happens in the next application that'll want to use this IoC API? It might not have the protocols this application contains, a case which will force me to update the IoC API for each application. Is there a way to keep my IoC wrapper generic - make it fit for any application no matter that types it contains? If you have any ideas in mind please share them with me!
Thank you
Edit:
I'll try to make it clearer, I use Autofac only. This "wrapper" is a project with the references to autofac that supplies basic API of IoC. For now I use this project only in application1.
But If tomorrow I start developing application2 I want to use this same wrapper. Therefore I can't have factories in my wrapper project that fit for a specific application. This is my issue
I've been following This MSDN tutorial about implementing OWIN to manage a single instance of DbContext and Identity UserManager classes.
It seems nice, but I'm also learning about Dependency Injection (I've been using Ninject) to get instances of objects.
I understand that OWIN creates and retrieves a single instance of an object per request and DI will return a new instance for every time that we require an object.
Do the two work together or share common features?
Should I be choosing one or the other or both together?
For example, should I be setting up an interface that has methods to return instances of my objects from the OWIN context and then injecting that into my controller?
The CreatePerOwinContext/Context.Get approach is not a general replacement for a regular IoC container and does not contain the [expected] features associated with dependency management - trivially, it provides no method for injecting dependencies. If anything, it is more akin to a basic Service Locator or [ab]use of the HttpContext.
Thus, while it can be used to establish an IoC container, it does not replace DI or an IoC container.
I'm using Ninject 3.0.1.10, MVC 5.0.0, FluentValidation 5.0 and finally FluentValidation MVC plugin library.
I'm trying to configure Ninject so that it injects a service into my AbstractValidator classes. I've read a lot of other answers about how to do this, but none have quite made sense to me. They all mention AssemblyScanner, which I can't find. They also mention accessing the IKernal from App_Start, but in my project App_Start does not have access to the IKernal because it's created inside of a NinjectWebCommon.cs file.
So I'm confused as to how to properly make this happen. Anybody have any clarity on this? Thanks.
You can access the IKernel configured by NinjectWebCommon.cs anywhere in your application. Of course, this usually is not recommended since it's a smell of Service Locator anti-pattern.
But there are cases where we can't escape from it, specially when mixing the frameworks and in your composition root, it's ok.
So, wherever you need, just use:
using Ninject;
//My class that will need access to the IKernel
var kernel = (new Bootstrapper()).Kernel;
The Bootstrapper class is initialized in App_Start.NinjectWebCommon before even the Application_OnStart runs. So it is safe to use even in Global.asax to obtain a reference to the IKernel. It remembers the kernel instance that was provided to it via a static variable inside the Bootstrapper class.
Hope that helps!
Guys I need your help I am using Castle Project Windsor IoC container in my C# Winforms application. I have services classes which has DI by constructor passing in implementing Repositories. I used Windsor to register them all Component.Register(...etc but everytime I use my service class I am calling resolve. for example:
var employeeService = container.Resolve....etc
is there any other way not having to call resolve all the time?
in ASP.NET you can just register them all then set the Controller factory: ControllerBuilder.Current.SetControllerFactory(new WindsorIoCFactory());
with this I can just use my controllers(using services) directly without calling resolve. how do you do this in winforms?
You should use a Composition Root approach.
In short, you should use Resolve only once at the App-StartUp basically resolving the MainView and through that you should be able to obtain all views(most likely through a TypedFactory) and their dependencies with no explicit Resolve call.
Service locator approach, as per comment link, is a deprecable anti-pattern specially when Composition Root can be used instead.
On the windsor wiki you'll find a sample based on a Silverlight app, very close to a Winform scenario.