Andrey Shchekin's Blog - Latest Comments in Comparing .NET DI (IoC) Frameworks, Part 2

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Naser — Fri, 06 May 2011 06:51:25 -0000

Great article. But a bit dated. A update will do a lot of good.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Martin — Mon, 20 Dec 2010 22:44:33 -0000

If curious about the performance of some of the most popular IOC containers take a look www.iocbattle.com.
Dynamo included is my own project to test how fast it is possible to go.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Haarentfernung — Fri, 17 Sep 2010 13:01:25 -0000

Thanks for sharing this interesting article.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Jos Krause — Fri, 02 Jul 2010 05:51:44 -0000

Now would be a good time :-) Most frameworks are much more matured now and are sporting nice new version numbers, thanks a lot for all the investigation and time you spent on writing all of this, it was a very helpful read! :_)

Re: Comparing .NET DI (IoC) Frameworks, Part 2

rechnungschreiben — Thu, 15 Apr 2010 14:54:25 -0000

Great article, very interesting. Thanks for sharing

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Lowrance Mark-5x Pro — Fri, 19 Mar 2010 15:42:55 -0000

Thats very interesting. thanks for sharing.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Angelreisen — Sun, 06 Dec 2009 01:45:25 -0000

Awesome, thank you for sharing.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Alleinunterhalter Köln — Mon, 30 Nov 2009 06:06:58 -0000

I think frameworks a little bit complicated, but it does an awesome job for sure.
Thanks for sharing.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Andrey Shchekin — Thu, 08 Oct 2009 04:58:41 -0000

I see what you are trying to achieve more as MEF/System.AddIn functionality than as basic IoC.

I will look at it when time allows, in the meanwhile you can use test suite at
http://code.google.com/p/ne...
to see how it corresponds to common IoC features.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Guest — Wed, 07 Oct 2009 12:57:28 -0000

Please, cay you see my framework http://plugins.codeplex.com. I'm luck of time so it hadn't been documented yet, but i'm very interested in comparison to other frameworks.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Veyton — Fri, 17 Jul 2009 21:02:48 -0000

awesome articel, thanks for sharing but sometimes frameworks are a bit difficult.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Pavan Kulkarni — Tue, 30 Dec 2008 19:02:18 -0000

Fantastic comparison. Thanks for sharing

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Busby SEO Test — Thu, 11 Dec 2008 14:22:23 -0000

Really like the overview and nice comparison too!

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Eric J. Smith — Fri, 10 Oct 2008 12:24:10 -0000

Great review! This is exactly what I was looking for to help clear things up for me.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Colin Jack — Thu, 25 Sep 2008 05:26:16 -0000

Good review, thanks for taking the time to do it.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Andrey Shchekin — Thu, 25 Sep 2008 02:29:47 -0000

The use case is to create a factory which registers several factory-specific components without polluting the original container with these components and their local scope dependencies (such as connection data). I describe the problem in detail at http://blog.ashmind.com/ind... .

So, if I can create a container in place and then throw it away, it also solves the pollution problem.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Nicholas Blumhardt — Wed, 24 Sep 2008 23:29:51 -0000

On IService[] - point taken, issue raised. In the meantime you can do:

builder.Register(c => c.Resolve<ienumerable<x>>().ToArray());

..in order to adapt the default collection type onto an array type.

I'll look into the non-generic collection registrations - may look into that in the future if there is demand.

Thanks for the feedback!

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Nicholas Blumhardt — Wed, 24 Sep 2008 17:12:26 -0000

The net effect is almost the same. RegisterTypesMatching() and RegisterTypesAssignableTo() are lazy - there is no scan of loaded assemblies, for instance.

You could always create an extension method ResolveUnregistered() which could check/register first, too.

Not sure what you mean about hierarchical containers relating to this use case - can you clarify a little?

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Andrey Shchekin — Tue, 23 Sep 2008 10:28:36 -0000

Definitely not all, I think I'll add a test for that at some point.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

alwin — Tue, 23 Sep 2008 06:43:11 -0000

Nice comparison! I didn't know that there where so many IoC frameworks :)

Do you know if all containers support registering services/components at any given time?
I know Castle can do that, i'm abusing it a bit in my current project.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Andrey Shchekin — Tue, 23 Sep 2008 06:11:07 -0000

Sure, I like the second approach much more.

By the way, is it possible to resolve unregistered types in Autofac?
I do not feel that is very important, given hierarchical containers, but I am still interested.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Andrey Shchekin — Tue, 23 Sep 2008 06:07:50 -0000

Thanks!

You have a very interesting implementation.
I would prefer to have an automatic registration by default, since if I get into situation where I would need more than one ILogger collection, I would probably use some kind of contextual override for a requiring component anyway. But it is a question of preference.

There are only two things that I feel are missing in your implementation -- support for IService[] (since it is simplest way to define collection dependency) and and ability to register collections using non-generic API.

Due to the first one, I can not update tests to pass right now, however, I had fixed the chart and will fix the post text as well.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Andrey Shchekin — Mon, 22 Sep 2008 16:50:55 -0000

Cool, great work!

I think I can't update in-post chart, since it'll require me to update post text as well, and that would mean I have to consider and mention all other framework updates.
I am looking for a way to keep an up-to-date version of charts at the net-ioc-frameworks page of Google Code, I hope to do it soon enough.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Nicholas Blumhardt — Mon, 22 Sep 2008 10:42:40 -0000

Aaah - and regarding automatic registration - you can always do:

builder.RegisterTypesAssignableTo<object>();

:) Not really recommendable though.

I recently ported some Prism code from Unity to Autofac, and used something similar to:

builder.RegisterTypesMatching(t => t.Name.EndsWith("View"));

--- just to illustrate that there is no need to use tagging interfaces or inheritance in order to work with this feature.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Nicholas Blumhardt — Mon, 22 Sep 2008 10:36:11 -0000

Hi Andrey,

Wow! It is very interesting to see a methodical approach to this comparison.

Autofac does also support list registrations - but like 'resolve anything' you have to opt-in. See: http://code.google.com/p/au....

As you've hinted at - like most containers you can change this behaviour by writing custom extensions. In general, you'll find Autofac is very conservative about working absolutely predictably by default.

Cheers,

Nick