title: Using Ninject with ServiceLocater pattern - good or bad
body: <p>I'm about to get used to Ninject. I understand the principles of Dependency Injection and I know how to use Ninject. But I'm a little confused right now. The opinions drift apart when it comes to the Service Locator pattern.</p>
  
  <p>My application is built upon a strictly modular basis. I try to use constructor injection as much as I can and this works pretty well, though it's a little bit messy (in my opinion).</p>
  
  <p>Now when an extension (external code) wants to benefit from this system, wouldn't it be required to have access to the kernel? I mean right now I have one static class which gives access to all subsystems of my application. An alternative would be having access to the kernel (Service Locator pattern) and grabbing the subsystem dependencies from this one.
  Here I can easily avoid giving access to the kernel or to be more explicit, not allowing dependencies to the kernel.</p>
  
  <p>But if an extension now wants to use any components (interfaces) of my application, from any subsystem, it would be required to have access to the kernel in order to resolve them because Ninject does not automatically resolve as long as you're not using "kernel.Get()", right?</p>
  
  <p>Peww, it's really difficult explaining this in an understandable way. I hope you guys get what I'm aiming for.</p>
  
  <p>Why is it so "bad" having a dependency to the kernel or a wrapper of it? I mean, you can't avoid all dependencies. For example I still have the one to my "Core" class which gives access to all subsystems.
  What if an extension wants to register it's own module for further usage?</p>
  
  <p>I can't find any good answer for why this should be a bad approach, but I read it quite often. Moreover it is stated that Ninject does NOT use this approach unlike Unity or similiar frameworks.</p>
  
  <p>Thanks :)</p>