NInject: Where do you keep your reference to the Kernel?
Asked Answered
Q

3

48

I'm using NInject on a new web application and there are two things that are unclear to me:

  1. Don't I need to keep a reference to the Kernel around (Session/App variable) to insure that GC doesn't collect all my instances? For example, if I specify .Using() and then the Kernel object gets collected, aren't all my "singletons" collected as well?

  2. If I do need keep a reference to a Kernel object around, how do I allow the arguments passed in to WithArguments() to change or is that not possible.

Quintero answered 26/2, 2009 at 15:3 Comment(0)
S
29

It's true that you don't want to pass around the kernel. Typically, in a web app, I store the kernel in a static property in the HttpApplication. If you need a reference to the kernel, you can just expose a dependency (via constructor argument or property) that is of the type IKernel, and Ninject will give you a reference to the kernel that activated the type.

If you use WithArguments() on a binding, they will be used for all activations. If you use IParameters, they will only be used for that activation. (However, if the service you're activating has a re-usable behavior like Singleton, it won't be re-activated even if you pass different IParameters.)

Sailplane answered 26/2, 2009 at 16:39 Comment(2)
That sounds like exactly what I want...can you post some code for this?Quintero
@Nate: not entirely related, but do you have any ETA on the CommonServiceLocator adapter? I see there's an adapter on the experiments branch for ninject2...Duran
D
16

This is a common pitfall when starting to use a IoC container. See this related question.

In a nutshell:

  • It's bad practice to pass your container around (been there, done that, and it really hurts)
  • If you really need to invocate directly the container, first consider abstracting to an injected factory, then as a last resource consider using a static gateway to the container
Duran answered 26/2, 2009 at 15:20 Comment(5)
I agree I don't want to pass the container around, but could I stash it in an Application variable for instance? My problem is that every time I do new StandardKernel(new CustomModule()) I get new instances of everything.Quintero
You only need one StandardKernel per app. If you need to load multiple modules just call kernel.Load(new MyModule()); kernel.Load(new AnotherModule()); etcDuran
Ok, so that makes sense. What I need to do is change the arguments in WithArguments() each time I ask for a type...is there any way to do this? Ultimately what I'm trying to do is implement a OnePerSessionBehavior and I want the binding to inject current arguments for each session.Quintero
That's a whole other question... post a new question with that issue specifically.Duran
New post is here: #591862Quintero
A
-4

Mark Seeman -- author of Manning Dependency Injection Suggust to Use Hollywood principle Don't call us(IOC framework) instead We will call you ... .. The IOC container should be placed in the Application's Composition root.. and it needs to instantiated as requested.. like wat nate mentioned

.. For the Web Application the Composition root is Global.asax file where the u can use the override the startup events and There u can bind your Ninject to resolve the component

Acroterion answered 22/3, 2011 at 4:21 Comment(2)
-1, mainly because the answer is phrased in such a fuzzy and vague way. Also, the part that says "it needs to [be] instantiated as requested" can mean really anything and is not helpful as a guideline at all. That being said, I would certainly support what's said about the "Hollywood principle" and the composition root being the only thing that should be retrieved directly from the DI container.Perth
This answer doesn't help, as it's only repeating the contents of the link. You haven't said what the Composition Root should be, so you can just cross out the words 'IOC Container' and write 'Composition Root' and it be the same question...Feminism

© 2022 - 2024 — McMap. All rights reserved.