Andrey Shchekin's Blog - Latest Comments

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

colorchart — Thu, 06 Nov 2008 15:00:43 -0000

great article... Ive never really been into .net myself but its certainly something im thinking about... your comparisons make interesting reading and maybe changed my mind in what direction to take.. very well written article thank you.

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

David — Sun, 19 Oct 2008 22:11:53 -0000

Enjoyable Read! thanks for your time..

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

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

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

Re: Some thoughts on ASP.NET AJAX Roadmap

Robert — Sun, 28 Sep 2008 21:14:22 -0000

Thank you, very informative, I am looking forward to see more thoughts on APS.NET AJAX 4.0

Re: Mocking internal interfaces with Moq

Patrick — Thu, 25 Sep 2008 13:28:55 -0000

Great, I was looking for that everywhere! Thanx!!!

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

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

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

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

ashmind — Thu, 25 Sep 2008 06: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/index.php/2008/06/23/di... .

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 — Thu, 25 Sep 2008 03: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 21: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

ashmind — Tue, 23 Sep 2008 14: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 10: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

ashmind — Tue, 23 Sep 2008 10: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

ashmind — Tue, 23 Sep 2008 10: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

ashmind — Mon, 22 Sep 2008 20: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: Programming is complex: HTML5 data-*

Ian Hickson — Mon, 22 Sep 2008 19:51:40 -0000

Eugenics aims to solve merely one: the devolution of our civilisation. That this is happening, and that it is a logical outcome of the egalitarian "political correctness" that our society is obsessed with, is a verifiable fact.

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

Nicholas Blumhardt — Mon, 22 Sep 2008 14: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 14: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/autofac/wiki/Collections.

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

Re: Programming is complex: HTML5 data-*

ashmind — Mon, 22 Sep 2008 08:24:35 -0000

ASP.NET was a solution that was expected to be 'simple for developers'. Just drag&drop some things and get the work done.
That worked, to some extent. In the same way the data-* would work, as long as the task is not complex enough.

ASP.NET MVC is the flexible solution. For some people, it might not be as easy to use or understand as original ASP.NET.
However flexibility has proven to be very important, important enough for Microsoft to spend time and resources to develop it.
Would the original ASP.NET be created, if Microsoft started with ASP.NET MVC? I am not sure.

Re: Programming is complex: HTML5 data-*

ashmind — Mon, 22 Sep 2008 08:14:48 -0000

People who write awesome JavaScript code _are_ programmers. Their job may be named 'designer', but it is a misnomer.
If a person writes good JavaScript, then he is a JavaScript programmer, and people writing really good JavaScript have no problems understanding complex things -- namespaces are a piece of cake compared to prototypes.

Re: Programming is complex: HTML5 data-*

Steve — Mon, 22 Sep 2008 07:33:08 -0000

Hmm, I believe you're mixing up several completely unrelated topics. X/HTML 5 is not for the programmer and therefore should be as simple as possible, even if it means mimicking XML functionality. The paragraphs about standards (language stuff) and ASP.NET MVC are completely unrelated to the X/HTML 5 debate. While data-* is about programming, you may want to ask yourself how many web designers are not programmers, nevertheless, writing awesome JavaScript code? data-* is made for them not primarily for programmers in its conventional perception.

Additionally, I do not fully understand the last paragraph. What are you trying to say? What does ease of use have to do with ASP.NET MVC? It's a design pattern, not more. More importantly, it is something that exists in other languages for ages which MS thought of being completely unnecessary. MVC is neither an "easy solution" nor a "shortcut" of some kind.

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

Philip Laureano — Mon, 22 Sep 2008 06:34:52 -0000

Hi Andrey,

If you take a look at the updated version of your test project, you'll notice that LinFu passes every test in both "MustHave" and "ShouldHave" categories--all from an assembly that is only about 94KB in size! :)

If you can, please update your charts accordingly. Thanks!

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

ashmind — Sun, 21 Sep 2008 09:39:20 -0000

Good idea! I supposed that all frameworks that support list injection for constructors support them for properties as well.
But documenting assumptions this in a testable way is always a good idea. I'll do this.

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

Philip Laureano — Sun, 21 Sep 2008 09:35:47 -0000

Thanks, Andrey! I went ahead and added the LinFuAdapter to the test suite.

Btw, you might want to add property service list injection as one of the "should haves" for IoC container features. For example, if I have a service instance with a property such as:

[SomeCustomPropertyInjectionAttribute] // This differs with every IoC container
public ISomeServices[] MyServices { get; set; }

It would be nice to have the container automatically instantiate the existing list of ISomeService instances from the container and inject it to the MyServices property. What do you think?

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

ashmind — Sun, 21 Sep 2008 09:31:09 -0000

Sure, it's a thing I forgot to do correctly.
There is already a Create<T> method in the IFrameworkAdapter, but test did not use it.
I have just modified the test to use Create<T> instead of Resolve<T>.

So get the latest version, then implement Create<T> using AutoCreate.

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

Philip Laureano — Sun, 21 Sep 2008 08:42:03 -0000

Unregistered Resolution is an ability to reuse container resolution logic for a given concrete type, without polluting the container itself with this type.

Ahh, I see! Now that you've mentioned it, LinFu *does* support unregistered resolution, but its not implemented quite the same way as other contains would implement it. For example, if I had an unregistered class like:

public class MyClass
{
public MyClass(ISomeService service)
{
// ...
}
}

You can create the unregistered class in LinFu using the following code:

// ...construct the container somewhere here
container.AddService<ISomeService>(new SomeService());
var myClass = (MyClass)container.AutoCreate(typeof(MyClass);

Now the tricky part here is that I've been running LinFu through your battery of tests, and I can't seem to get it to pass the UnregisteredResolution test. Is there anyway to modify the logic so that each library has a way to implement their own unregistered resolution? Clumping it all under a single Adapter.Resolve() call doesn't seem to apply, in this case.