Skip to content

Ninject 2 Reaches Beta!

February 25, 2009

Since I published this post, I’ve moved the Ninject 2 source to Github. Both the downloads available here and the experimental branch in Subversion is outdated and will be removed eventually. Read more here.

A month or so ago, I started a spike of a new version of Ninject to test out some ideas that have been floating around in my head. I fully intended to throw it away and integrate what I’d learned into the existing Ninject codebase – but gradually the spike grew into what I’m now calling Ninject 2, which I’m proud to say has reached beta status!

Ninject 2 is essentially a rewrite of the original codebase, but that’s not to suggest that anything is particularly wrong with the  code that went into Ninject 1.x. When I started writing Ninject in early 2007, I was targeting .NET 2.0 and didn’t have the fancy toys that I have now – namely LINQ and expression trees. Ninject 2 takes full advantage of LINQ, and I’ve actually jokingly referred to it as “LINQ to IoC”.

Also, I felt that some parts of Ninject 1.x were over-designed, so the development of Ninject 2 has been driven by an obsession with simplicity. To give you an idea of how much simpler Ninject 2 is, the trunk build of Ninject 1.x weighs in at 177KB, and Ninject 2 is just about 80KB.

I’m going to be blogging about the design of Ninject 2 and the differences between it and Ninject 1.x quite a bit over the next few weeks, but here’s a quick overview:

Things that are in Ninject 2 that were not in Ninject 1.x:

  • Cache-and-collect lifecycle management: Rather than using binding behaviors, Ninject 2 uses a scoping system and leverages the garbage collector to reclaim instances. I’m very excited about this improvement, and it deserves a post unto itself to explain it.
  • Multi-injection: The kernel in Ninject 2 now has GetAll<T>() methods, and supports injection of multiple targets with types IEnumerable<T>, List<T>, and arrays of T.
  • Constrained resolution: Rather than just declaring conditional bindings, constraining predicates can now flow into a resolution request from the point of injection. This creates a very powerful push/pull system for resolution, which also deserves its own post. :)
  • Common Service Locator support: Because of multi-injection, Ninject 2 now has full support for the CSL.
  • Optional modules: You can now register bindings directly on the kernel; modules are optional. If you register bindings in a module, and then unload the bindings, the bindings will be un-registered.
  • Automatic module scanning: Ninject 2 can scan directories for assemblies that contain modules, and load them into the kernel.
  • Simplified extension model: Internally, Ninject 2 relies on an inversion of control container of its own, reducing factory bloat and making extension of the core much simpler.
  • Mono support: I haven’t had a chance to test this very well, but it’s something I want to make sure Ninject 2 has.

Things that were in Ninject 1.x that are not in Ninject 2:

  • Support for .NET 2.0: Since Ninject 2 relies on LINQ and expression trees, .NET 2.0 support is now no longer possible.
  • Field injection: Ninject 2’s injection is now driven by expression trees, and in .NET 3.5 there is no way to set field values with an expression tree. Since this is a bad practice anyway, I decided to cut it.
  • Private member injection: Again, not supported by expression trees, and a bad practice, so it has been cut.
  • Behavior attributes: Since behaviors have been cut and replaced by GC-driven scopes, attributes like [Singleton] no longer make sense. I may re-add these if people scream loud enough.
  • Logging infrastructure: Cut because it wasn’t really useful anyway. Ninject doesn’t generate logging messages of its own anymore, but I’m looking into alternative sources of introspection.
  • AOP/Interception: This has been removed from the core for simplicity.
  • Compact framework support: This is missing from the beta, but I may re-add it for the official release.

A few notes:

  • The core namespace is now just Ninject instead of Ninject.Core.
  • The default scope is now singleton rather than transient.
  • Some extensions are missing (Messaging, in particular). They may re-appear before release.

Ninject 2 also has new constructor selection semantics:

  1. If a constructor has an [Inject] attribute, it is used. If multiple constructors have an [Inject] attribute, the behavior is undefined.
  2. If no constructors have an [Inject] attribute, Ninject will select the one with the most parameters.
  3. If no constructors are defined, Ninject will select the default parameterless constructor.

Right now, the source is in an experimental branch on the Ninject subversion repository, but it will soon be moving to the trunk. You can also download the various builds here.

I’m interested in all feedback (good and bad), so please let me know what you think!

About these ads

From → miscellaneous

29 Comments
  1. Congrats man!

    Amazing stuff! keep it up

  2. Awesome news…
    but without field injection there is no way to inject properties into object created by someone else.

  3. I *could* re-implement field injection with reflection only, if it’s a feature that enough people care about. It’s just really not a good idea to use it. :)

  4. Michael Hart permalink

    I feel like a kid at Christmas with the anticipation :-)

    Am using it now without issue, bar the implicit ASP.NET MVC controller binding issue I tweeted about – it feels beautifully light, a floating piece of elegance.

    Well done!

  5. Hey, that’s a good news!

    Thanks for your work.

  6. Is there a dedicated build forseen for the Compact Framework v3.5 (like there is one for NInject 1.0), or is NInject 2.0 of the kind “One-Size-Fits-All”?

  7. Ops… I misread the post… Field Inject DO is bad…
    I thought you were removing Property injection…
    sorry for the confusion

  8. From my perspective, excellent decisions all along. The missing Multi-Inject was rather painful and I am glad it’s coming. Everything else sounds very nice. Looking forward to what you’re rolling out :)

  9. Support for CF was one of the things that drew me to Ninject in the first place. I like the idea of only having to deal with one IoC across the full framework, SL and CF. So consider this a +1 vote for CF support.

    Other then that, all the changes you’ve made sound awesome and I can’t wait to try it out, and also take a look at the source to see how you accomplished it.

    Thanks for a great IoC.

    Adam

  10. Nate, you are the man! Looking forward to seeing Ninject grow in the future.

  11. Thomas Skovsende permalink

    I’m a bit bummed about the loss of AOP – how much do I have to scream to get that in? ;)

    Or, is it because of your lack of time it’s not there, or is it because it would be hard to add to Ninject2?

  12. Well, I like the field injection feature of Spring when using 3rd Party components which have not the setters I need. However I think this is only rarely needed.
    Thanks for the Common Service Locator support!

  13. Dave permalink

    Please don’t add support for private member/field injection in Ninject 2. As the post says private member/field injection is a bad habit.

    IoC should be used to make projects more maintainable (readable). Someone new to a project might have a hard time figuring out where that dependency comes from. When you have a property it’s instantly clear that the dependency is assigned.

    Devvers who don’t want that other components (if the class itself ins injected into other parts of the application) use the injected classes should use setter-only properties or a method marked with the Inject attribute.

    And besides that. Don’t you think you also have a moral tasks to prevent users of Ninject to make stupid decisions like using field injection ;-)

  14. Peter Meyer permalink

    Nate,

    Any plans to include WCF extensions (i.e. ServiceHost and behavior capable of DI) with Ninject 2?

    You’ve a great library here. Looking forward to taking a look at Ninject2.

    Thanks for the effort so that we may benefit.

    Pete

  15. Bill permalink

    2.0 sounds very exciting, but support for CF is a definite must.

  16. PandaWood permalink

    The codebase I’m working on that works with Ninject1, throws with Ninject2.0 beta. I can’t work it out why (System.ArgumentException: Expression of type ‘System.TimeSpan’ cannot be used for return type ‘System.Object’)
    I’ll have to bail on using it, as I need to get some work done.
    But will come back to it and see if I can help figure it out.

  17. [quote]If no constructors have an [Inject] attribute, Ninject will select the one with the most parameters.[/quote]

    What’s your reasoning for changing this behaviour? It seems to me to cause problems since several implementations of IMyInterface may have completely different constructor parameters.

    Is there a way to change it back to the original behaviour of using the Default Constructor if no [Inject] attribute is applied?

  18. Nate,

    We chose Ninject because of its .NET CF support. We love it, but really need the multi-injection support. Please keep CF support as the valuable feature it is.

    Thanks,
    Eric

  19. Ross permalink

    Ninject 2.0 has some great features we’ve been looking for including Multi-Injection. However one of the reasons we chose Ninject was due to the CF support. Please add CF support to 2.0!!

  20. Eric Hamrick permalink

    Another person using Ninject 1.0 on mobile devices. Hoping to see 2.0 supported on CF as well. :)

    Eric

  21. Steven H permalink

    Please, dont drop CF support – Think about the children !!!!!!!

  22. Justin permalink

    Nate, I was actually getting ready to adopt unity for an IOC due to its service locater support. Great to see this will be in Ninject 2! Do you have a release date yet for v2?

  23. I just started using NInject and refactored a very small test application from Unity to NInject 2. The first thing I noticed: NInject error messages are far better than the cryptic error description of Unity. So, after spending about 15 minutes refactoring, all is up and running. Really cool!

    As others stated, I’d be glad if CF support would stay in. The reason is, that our company has a lot of “normal” .net projects as well as CF projects, and we like to be able to reuse our stuff and therefore the injection container.

    Keep up the great work
    Cheers
    Urs

  24. Eric permalink

    Hi Nate,

    I have started using Ninject 1.x in a project, great tool!

    We have recently heard about MEF and after reading these articles
    http://blogs.msdn.com/nblumhardt/archive/2009/03/16/hosting-mef-extensions-in-an-ioc-container.aspx
    http://ondevelopment.blogspot.com/2009/03/unleashing-modules.html
    we are now considering using an IoC container with MEF.
    Unfortunately, Ninject does not provide an MEF adapter (like Autofac or Unity), but I wonder if the Automatic module scanning feature is actually doing something similar to what MEF does?

    Thanks

  25. +1 for Compact Framework support, this why I’m using Ninject.

    Congrats on the beta release!

Trackbacks & Pingbacks

  1. Reflective Perspective - Chris Alcock » The Morning Brew #295
  2. Dew Drop - February 26, 2009 | Alvin Ashcraft's Morning Dew
  3. Customizing Ninject 2.0 Behaviour to use the Default Constructor on InjectAttribute-less classes. « Ben Ellis’s Blog
  4. Using Ninject 2 to resolve conditional bindings with a kernel « Deliberating On Software Development

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: