First, you make a good point about the “container” name. I was thinking of it as a container because that’s what we built for our homegrown Delphi service locator (ours is basically a hashtable, so it really is a container). I’m still getting a handle on how IoC differs from that. One could make the case that the dependency injector does sort of contain the Singleton instances (something’s got to hold onto the references so it can return the same one again) — but that’s just as much an implementation detail as “kernel”, so you’re right, “container” is a bad name. Sometimes it’s a factory, but again, implementation detail. “Provider” might be a good alternative that describes how it’s actually used, without being tied to implementation. Or just “dependency injector”, when it’s being used to get a concrete class.

Second, I’ve heard the “nobody needs the [container/kernel/provider] after startup” party line before, and I just don’t buy it. That could work for tiny apps that are a single window with a single ViewModel, but as soon as you get more complicated than that, you need more than startup-time injection. As soon as you switch to another screen that does a different kind of analysis, you’re going to need to spin up a new View with a new ViewModel and even a new Model behind it, and they’re going to need dependencies injected into them somehow. The dependency injector is designed to do exactly that, so I don’t get why everybody says you shouldn’t use it after app startup.

}

Ninject inherits the term “kernel” from Windsor, which was one of the DI frameworks I used before writing Ninject. In contrast with you, I absolutely despise the phrase “inversion of control container”. In Ninject, the kernel doesn’t contain anything. It is the central point of access, but delegates everything to something else. As the central point of operation for Ninject — and therefore basically heart of an application based on Ninject, I believe “kernel” is a proper term. Maybe IPuppeteer?

Incidentally, if you’re interacting with the kernel directly often, you may want to rethink your design. Applications written with DI in mind should rarely touch the kernel itself, instead receiving dependencies through chains of activation whenever possible. In reality, the kernel should be your application’s Godfather, pulling the strings behind the scenes.