ninject Wiki & Documentation Rss Feed

New Comment on "User Guide"

ncistgg — Thu, 23 May 2013 09:55:47 GMT

this user guide is about niject1.0,is there any documentation about ninject2.0?where can i read it?

New Comment on "Modules and the Kernel"

loopdebugger — Thu, 24 Jan 2013 18:09:08 GMT

Bind<IWeapon>().To<Sword>(); I need "Bind" example please

New Comment on "Activation Behaviors"

loopdebugger — Thu, 24 Jan 2013 18:07:18 GMT

wait.... what is "Bind"? I can understand that part... is a method i know but what it does?

New Comment on "Injection Patterns"

skrzeczowas — Tue, 05 Jun 2012 09:32:50 GMT

Hi, If one leave off InjectAttribute, then: 3. If the type has more than one constructor, and has no default (parameterless) constructor available, Ninject will call first ctor that even partially matches. For example we have test code: using (IKernel kernel = new StandardKernel()) { kernel.Bind<ITaxCalculator>().To<TaxCalculator>().WithConstructorArgument("rate", .2M); var sale3 = kernel.Get<Sale3>(); Assert.IsNotNull(sale3); } And class to test: public class Sale3 { private ITaxCalculator _taxCalculator; public Sale3(ITaxCalculator taxCalculator) { _taxCalculator = taxCalculator; } public Sale3(ITaxCalculator taxCalc, int testInteger) { _taxCalculator = taxCalc; } } In this case test will be run successfully. If we reorder constructors that the one with integer as input parameter will be first, test will fail. So I believe that under the hood Ninject searches for first constructor that accepts desired Interface as an input paramter and then invokes this ctor. Am I correct?

New Comment on "Dependency Injection With Ninject"

hbrizuela — Wed, 11 Apr 2012 20:12:38 GMT

ooops... I guess I should keep reading

New Comment on "Dependency Injection With Ninject"

hbrizuela — Wed, 11 Apr 2012 20:10:34 GMT

having Bind<IWeapon>().To<Sword>(); means whenever I instantiate the class samurai my instance will have a weapon of type sword. Am I wrong? what if I want to create a list or Enumerable of samurai with different kind of weapon. will I have to do it by hand?

New Comment on "user guide"

jameskerry486 — Sat, 24 Jul 2010 04:46:13 GMT

i m glad i found ur blog.Not everyone can provide information with proper flow. Good post. I am going to save the URL and will definitely visit again. Keep it up.<a href="http://www.realcourseworkwriting.com" rel="dofollow">coursework writing</a> | <a href="http://www.realresearchwriting.com" rel="dofollow">research writing</a>

New Comment on "Modules and the Kernel"

ng2tuan — Tue, 30 Mar 2010 13:54:30 GMT

shit!

New Comment on "User Guide"

chillitom — Wed, 24 Feb 2010 14:27:12 GMT

Any chance I can get write perms so I can update this documentation (or create new documentation) for Ninject 2?

New Comment on "Dependency Injection By Hand"

DanAtkinson — Fri, 19 Feb 2010 10:27:36 GMT

This is just me being anal, but the actual output of warrior1.Attack("the evildoers") is "Pierced the evildoers's armor.".

New Comment on "User Guide"

bensturley — Tue, 16 Feb 2010 13:06:19 GMT

This documentation is not very complete. Where is detailed explanations of, for example, the contextual binding parameters and valid objects etc to use? E.g. - what is When.Request.Context.Target, and why doesn't it work with Only or OnlyIf bindings?

New Comment on "Dependency Injection With Ninject"

swingsetacid — Mon, 01 Feb 2010 22:15:37 GMT

You should probably keep reading. If you get two more sections ahead, it's all written out in fairly crystal clear detail. Not only will you see the benefits of a container, but it will also let you extrapolate how it would save you *tons* of effort in a more complex scenario.

New Comment on "Dependency Injection With Ninject"

jsmorris — Sat, 12 Dec 2009 04:28:51 GMT

It is hard to appreciate what an IoC "saves" until you need to construct an object that contains many dependencies that contain dependencies, which also contain dependencies and so on and so forth. These are just trivial examples to show the concept of DI via IoC (ninject). You wouldn't want to add the complexity of an IoC, unless you had and architecture that was suited to it: all objects that composed the final object followed the DI pattern.

New Comment on "Dependency Injection With Ninject"

SittenSpynne — Tue, 08 Dec 2009 23:27:09 GMT

Perhaps it would be more clear how this saves effort if the example showed how something would instantiate a Samurai instance once the attribute is in place? You have to call a constructor and pass an IWeapon, so what's Ninject doing that's not on display here?

New Comment on "Dependency Injection With Ninject"

dschobel — Tue, 08 Dec 2009 21:58:15 GMT

@Vaccanoll See this post on Stacked Overflow which answers your question: http://stackoverflow.com/questions/871405/why-do-i-need-an-ioc-container-as-opposed-to-straightforward-di-code . In short, for simple applications you don't gain much, but as the complexity of the application grows, it makes it a lot easier to maintain the wiring of your application and swap out implementations.

New Comment on "Dependency Injection With Ninject"

vaccanoll — Mon, 07 Dec 2009 22:38:19 GMT

Maybe I am just dense, but I am not getting what this saves yet? All the code from the "by hand" method seems to still be needed and the Samurai class is the same except it has the [Inject] tag. Though I do get that this is better than other models due to it not needing XML.... But what do we gain over doing it by hand?

Updated Wiki: How Injection Works

NotMyself — Mon, 12 Oct 2009 15:52:20 GMT

Ninject relies on reflection to analyze the types that it works with. However, since repeating calls via reflection can be very slow, Ninject can also take advantage of the lightweight code generation system introduced in version 2.0 of the CLR. By default, the StandardKernel will create dynamic methods (via System.Reflection.Emit.DynamicMethod) that can be used to inject values into the different injection targets. These dynamic methods are then triggered via delegate calls.

For example, given our Samurai type:

C#:

class Samurai {
  private readonly IWeapon _weapon;
  
  [Inject]
  public Samurai(IWeapon weapon) {
    _weapon = weapon;
  }
  
  public void Attack(string target) {
    _weapon.Hit(target);
  }
}

VB.NET:

Public Class Samurai
  Private ReadOnly _weapon As IWeapon

  <Inject()> _
  Public Sub New(ByVal weapon As IWeapon)
    _weapon = weapon
  End Sub
  Public Sub Attack(ByVal target As String)
    _sword.Hit(target)
  End Sub
End Class

Ninject will create a dynamic method that (basically) looks like this:

C#:

delegate(IWeapon weapon) {
  return new Samurai(weapon);
}

Then, whenever the StandardProvider associated with the Samurai needs to create a new instance, it resolves the IWeapon argument, and then passes it to the dynamic method, which in turn passes the IWeapon to the Samurai's constructor and returns the created instance.

Ninject can also be configured to use reflection for injection. Because there is some overhead involved with creating the dynamic methods, this can actually result in faster execution in some cases -- particularly when you have a large number of services, but they're all Singletons.

Continue reading: Contextual Binding

Updated Wiki: The Activation Process

NotMyself — Mon, 12 Oct 2009 15:26:32 GMT

Quite a bit of magic happens inside of Ninject when you call the kernel's Get() method. Here's a rough sketch of the procedure:

The binding of the type is resolved.
The binding is used to create an activation plan, which describes the means by which the instance will be created and injected.
An instance of the type is requested from the behavior defined in the activation plan. Depending on the behavior's implementation, the behavior may simply return an existing instance of the type, in which case the rest of the activation process is not executed.
If the behavior indicates that a new instance of the type is necessary, it is requested from the binding's provider. The provider resolves any necessary arguments and calls the injection constructor.
All properties are injected according to the activation plan.
All methods are injected according to the activation plan.
All fields are injected according to the activation plan.
If the type implements the IInitializable interface, its Initialize() method is called.
If the type implements the IStartable interface, its Start() method is called.

This entire activation procedure can also be customized by altering the strategy chain used by the Activator kernel component. (More on customizations later.)

Returning to our earlier example, we had a WarriorModule:

C#:

class WarriorModule : StandardModule {
  public override Load() {
    Bind<IWeapon>().To<Sword>();
    Bind<Samurai>().ToSelf();
  }
}

VB.NET:

Public Class WarriorModule
  Inherits StandardModule

  Public Overrides Sub Load()
      Bind(Of IWeapon).To(Of Sword)()
      Bind(Of Samurai).ToSelf()
  End Sub
End Class

And we activated an instance of Samurai like this:

C#:

class Program {
  public static void Main() {
    IKernel kernel = new StandardKernel(new WarriorModule());
    Samurai warrior = kernel.Get<Samurai>();
    warrior.Attack("the evildoers");
  }
}

VB.NET:

Module Module1
  Sub Main()
    Dim kernel As IKernel = New StandardKernel(New WarriorModule())
    Dim warrior As Samurai = kernel.Get(Of Samurai)()
    warrior.Attack("evil doers")
  End Sub
End Module

The activation process for the Samurai type is as follows. The number to the left indicates the depth at which the activation is occurring, and some steps have been left out for clarity:

(1) The kernel resolves the self-binding for the Samurai type that was defined in the WarriorModule.
(1) The kernel asks the Samurai's TransientBehavior to resolve an instance.
(1) The Samurai's TransientBehavior asks the binding's provider to create a new instance.
(2) The Samurai's StandardProvider asks the kernel to resolve an instance of IWeapon.
(2) The kernel resolves the binding from IWeapon to Sword that was defined in the WarriorModule.
(2) The kernel asks the Sword's TransientBehavior to resolve an instance.
(2) The Sword's TransientBehavior asks the binding's provider to create a new instance.
(2) The Sword's StandardProvider calls the Sword's parameterless constructor.
(2) The kernel returns the newly-created instance of Sword.
(1) The Samurai's StandardProvider calls the Samurai's injection constructor, passing it the instance of Sword as an argument.
(1) The kernel returns the newly-created instance of Samurai to the site of the method call in Main().

Whew! After all that, we end up with a Samurai armed with a Sword, and the call to its Attack() method results in the same output as our original example: Chopped the evildoers clean in half. Although this might look like a lot of work just to get the same outcome, keep a few things in mind:

All of this happens in the background, and you rarely have to think about what's really happening. It Just Works.
It actually adds much less overhead than it seems. Honest. :)
This is an overly simplistic example. The more complex your application becomes, the more the power of Ninject will appear.

Continue reading: How Injection Works

Updated Wiki: Providers and the Activation Context

NotMyself — Mon, 12 Oct 2009 15:24:24 GMT

Okay, so remember when we said type bindings were from a service type to an implementation type? Well, we lied. You caught us. Type binding is really a little bit more complicated than we let on. Rather than being from one type to another, bindings are actually from a service type to a provider. Simply put, a provider is an object that can create instances of another type. It's like a factory, but specifically designed to work with Ninject.

When you define a binding from a service type to an implementation type, like the binding from IWeapon to Sword in the previous example, you're really declaring a binding from IWeapon to a special built-in provider called StandardProvider. This StandardProvider is like a "super-factory", in that it can create instances of all sorts of types. It also understands how to resolve the arguments to inject into constructors.

All of this stuff happens behind the scenes, though, and you rarely need to worry about it. However, sometimes you might want to do some sort of complex custom initialization to your objects, rather than letting Ninject work its magic. If you need to (or if you're just a control freak!), you can create your own provider and bind directly to it:

C#:

Bind<IWeapon>().ToProvider(new SwordProvider());

VB.NET:

Bind(Of IWeapon)().ToProvider(New SwordProvider())

Providers just need to implement the IProvider interface (in Ninject.Core.Activation):

C#:

interface IProvider {
  Type Prototype { get; }
  bool IsCompatibleWith(Type type);
  Type GetImplementationType(IContext context);
  object Create(IContext context);
}

Although this might look kind of complicated, the majority of custom providers don't need to implement the first two bits. The magic really happens in the Create() method. To simplify matters, Ninject also has an abstract type called SimpleProvider<T> that gives you the basics, and adds in strong-typing as well. Here's what SimpleProvider<T> looks like:

C#:

abstract class SimpleProvider<T> {
  // Simple implementations of the junk that you don't care about...

  public object Create(IContext context) {
    return CreateInstance(context);
  }

  protected abstract T CreateInstance(IContext context);
}

By using SimpleProvider<T>, custom providers just need to override the CreateInstance() method. Here's an example of a simple provider for our Sword class:

C#:

class SwordProvider : SimpleProvider<Sword> {
  protected override Sword CreateInstance(IContext context) {
    Sword sword = new Sword();
    // Do some complex initialization here.
    return sword;
  }
}

VB.NET:

Public Class SwordProvider
  Inherits SimpleProvider(Of Sword)
  Protected Overrides Function Sword CreateInstance(context as IContext)
    Dim sword As New Sword()
    'Do some complex initialization here.
    Return Sword
  End Function
End Class

This brings up another hidden complexity in Ninject, the context. See, Ninject is pretty smart. When it's resolving a big complex graph of objects, it keeps track of where it is, what's being injected, who's asking for it, etc. All of this information is stored in the context, represented by the IContext interface. If you need it, your provider can access all of this information to make decisions about how to resolve the dependencies. If you don't need it (like in the SwordProvider above), you can just ignore it.

Each time an instance is resolved, a new child context is created and the kernel's Get() is called again. Through this (somewhat) recursive operation, Ninject forms a stack of activation contexts, all of which are available throughout the system during the activation process.

Continue reading: The Activation Process