Pardon me if there's a similar question somewhere on here already, but I couldn't find one.
Anyway, I have an ASP.NET MVC 2 application using Ninject 2 for the DI. I'm setting up the constructors on my controller to have no parameters, meaning they'll have to instantiate the the needed Providers
. The problem comes when I have Providers
that have dependencies of their own such as Repositories
, which furthermore have dependencies of their own such as the DataContext
.
So, I'm curious if I can A) get objects out of Ninject such as the DataContext and pass it into the extremely long chain of instances I'll be creating or B) have Ninject construct the objects I need to pass in?
I looked around on the Ninject Wiki, but couldn't find a satisfying answer. Also, I hardly have any experience with Ninject, so treat me as a noob on that subject.
Anyway, thanks in advance!
P.S. Not sure if this matters, but I'm doing this because of an "No parameterless constructor defined for this object.
" that appeared out of nowhere and cripled my application. Idk what caused it all of the sudden, but the app was working fine without "parameterless constructors" and Ninject doing its thing. If someone has suggestions on fixing开发者_如何学C that and avoiding everything else above I am all yours.
UPDATE (in reference to @JC)
Well, I'm sure I'm inheriting from NinjectHttpApplication
and then I'm doing this in Global.asax:
protected override IKernel CreateKernel() {
var Kernel = new StandardKernel();
Kernel.Bind<DataContext>().ToSelf().InSingletonScope();
return (Kernel);
}
I'm not binding any repositories or services here because the ones I have don't use interfaces because the application was born without DI or Repositories, but received the upgrades last week. That and quite frankly I'm 50/50 if I want to interface everything, but that's besides the point.
What I do want to stress is that this worked just fine for like a week and a half (minus bugs here and there that I corrected), it just suddenly stopped. I get what the exception above says, but the application was working fine without "parameterless constructors" fine until now. I'm not even sure it's the controller that's the cause. Can a class being instanced during the whole process be the cause, but since the controller triggered the processing, it gets blamed for the exception (I'm only referring to the stack trace that says the controller was the cause)?
There are a couple of ways to do this one (that I know of):
Make your application extend the NinjectMvcApplication class, The application is contained within your Global.asax.cs file. Then override CreateKernel method, instantiate a your module containing your bindings and then return a new kernel, like this:
protected override IKernel CreateKernel() { var modules = new INinjectModule[] { new YourModule() };
}return new StandardKernel(modules);
Your binding module should contain bindings for your controller and its dependencies. If your controller instantiates repo's and other things in order to perform its task then they are really dependencies and you should really make then constructor parameters.
Another approach (more long winded) approach is to create your own controller factory class that extends DefaultControllerFactory class. There are a bunch of methods you can override but one you should definitely override is:
protected override IController GetControllerInstance( RequestContext requestContext, Type controllerType);
Inside the body of this method you would load the kernel with your bindings in the normal way and then ask your kernel to provide you an instance of the requested controllerType:
kernel.Get(controllerType)
.
Of course you may not wish to create and load new kernels for each request so you decide to cache some stuff in order to be more efficient.
I prefer to use option 1 but that's just me.
Okay, so I got it figured out. After I had asked another question in my update above in reference to @JC I started thinking about it some more. I went to where I thought the problem was coming from (which wasn't the controller as I assumed) and started selectively adding in dependencies until it failed.
I finally found the dependency that was the cause and figured out why. I have a BaseProvider
for low level supporting objects and a OfficeProvider
for working with Office
objects and everything related to them. Well, BaseProvider
needed an instance of OfficeProvider
to construct the DashboardView
(which is the model for the view); however, OfficeProvider
needed an instance of BaseProvider
for its own view model constructions. Thus I was causing an infinite instancing loop which somehow resulted in the exception I originally got.
The lesson learned, cross-dependent classes are bad... Being that it's ~2:30 AM right now, I'm gonna blame sleepiness for my screw up.
>:3
精彩评论