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.
Related
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.
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.
I'm creating an MVC 5 site with Web API 2 functionality inside it as well and I'm wondering how I should work with the fact that ASP.NET uses 2 different resolver instances for resolving MVC controllers and ApiControllers.
I found this article that explains how to configure the resolution, but it looks like it uses 2 separate container instances and doesn't explain how to register dependencies for each. It's just like "do your registration here."
Following the 2-container example, I was tempted to set up the app so that the Web API container only has Web API dependencies and the MVC container only has mvc controller dependencies, but I feel like in the situation where a component is used for both, having a subset of items used in both containers would be too much work to maintain correctly.
Is it okay to just have all of the dependencies installed in each container? Or is it better to use the same container in each resolver?
Edit: I'm not using Unity so I'm writing a resolver class to wrap Windsor. I'm considering having my resolver implement both interfaces and just assigning the same instance as the different resolvers as well.
I've a c#.net project that uses multiple 3rd party dlls. These dlls exposes interface that are used throughout the project. My question is this: These interfaces are passed to the constructor of Controller class like this:
HomeController(IClientData clientdata, IClientRecord clientrecord)
{ }
Here clientdata and clientrecord are initialized to a default value needed to start the view(produces a list of client details). I've to use these initialized data somewhere else in my project but I don't know how to get these default initialized values.
What you have seen is a very general pattern in ASP.NET MVC . Here your home controller has 2 dependencies (one class inherited from IClientData and other from IClientRecord) . These dependencies are usually injected by some DI framework .
There are some good DI frameworks available for ASP.NET MVC
Unity
Autofac
Castle Windsor
StructureMap
etc...
and they usually provide two ways to setup the dependencies -
through XML configuration files
Fluent interface (inside code)
When Fluent interface is used, a general practice is to create a separate class file inside App_Start folder and call it from global.asax (Application_Start).
I've just created an MVC project using the .NET 4.5 framework with controllers in a separate class library.
I had previously thought that if the controllers are in separate class library you need to create a custom controller factory as discussed in this SO post. However, my controllers are being instantiated and are working fine without having to do this.
How does the framework (the newer ones at least) know to use the controllers in the separate class libary without being told to do so? All I needed to do was add a reference to the controllers project.