Dependency Injection framework (.Net) about tech-radar HOT 10 CLOSED

I've used Autofac on Figleaf and Ninject on Compare. I have a slight preference for Ninject because Autofac lets you write builder.RegisterType<CompletelyUnrelatedType>().As<IInterfaceIActuallyWanted>(); which IIRC is a compile error with Ninject's API. Apart from that they're basically equivalent as far as I can tell - never used them in a performance-sensitive manner since we mostly just inject high-level services.

from tech-radar.

Whereas I disagree almost entirely. I find Autofac easier to read and use, more powerful (lists, factories, and lifetimes controlled in an intuitive way with IEnumerable<T>, Func<T>, and Lazy<T>/Owned<T>) and I prefer its opinionated approach (configure then build, the injectee doesn't get to control how things are injected in to it, etc.).

Autofac does decorators too (https://autofaccn.readthedocs.io/en/latest/advanced/adapters-decorators.html) - the registration is just potentially backwards to the way you're thinking of.

(as an aside, I think overuse of that decorator pattern is bad anyway - a lot of the time it strikes me as a way of using something very like inheritance without taking advantage of the language support, just because inheritance is bad. I'd prefer most things that use decoration to be using chaining/composition instead)

from tech-radar.

Sounds like this is a coin toss 😄 They both have almost the same amount of ⭐️ and questions on Stackoverflow.

There seems to be a slight preference for AutoFac (and from me I think the documentation for AutoFac looks great), so I'm going to suggest:

Adopt:

• AutoFac

Endure (since I don't think there's any benefit for removing NInject from projects that already use it)

• Ninject

PR welcome?

from tech-radar.

PR welcome?

I can PR this ✋

from tech-radar.

I would have thought that most of our codebases default to Autofac nowadays?

from tech-radar.

SQL Source Control uses Ninject (and so does SQL Compare Engine and the Oracle tools from doing a quick search).

from tech-radar.

We use Autofac on Clone. I've never used Ninject (when I look for comparisons, they mostly just note that Ninject is much slower than alternatives at resolving, or at least was).

from tech-radar.

(Sorry, fumbling around - didn't mean to do any of that)

from tech-radar.

Ninject also supports some common DI patterns way better than Autofac. The one I keep coming across is where you have two implementations of an interface, and you want everyone to use the first implementation (a decorator), except when constructing the first implementation, which needs to decorate an instance of the second implementation (the decorated). Personally I much prefer the usability and readability of Ninject over Autofac.

from tech-radar.

Aw, I was hoping that the decorator syntax might have improved since I last used it, based on your comment. But it's still as poor as I remember it. It involves naming things, being obliged to make those names match across statements, and one of the lambdas directly invokes a constructor, which is just the kind of thing I want a DI system to stop me having to do.

To be honest, whenever I've flipped between Ninject and Autofac as I've switched projects, they're essentially interchangeable in all the ways that really matter. It probably doesn't matter which one we pick, as long as we just pick one.

from tech-radar.