Response to fFastInjector concerns

Below are some comments from Daniel de Palme's IOC Container performance benchmark and my responses.

http://www.palmmedia.de/blog/2011/8/30/ioc-container-benchmark-performance-comparison Post #48

Something to notice about fFastInjector is that it is static, and it is made pretty much only for speed by creating a static generic class for every registration instead of storing them in some sort of collection like all the other (it does use a collection - but only to map resolving by Type to the static generic class).

fFastInjector is static but that is not only for speed. It also creates a very small and concise code base.

The thing to remember about dependency injection is that it is all about answering the question of "please give me an instance of (some type)."

In the case of an interface, the injector needs to determine where and how to get or create an instance.

In the case of a concrete class, the injector needs to know how to satisfy the dependencies the constructor has specified and which constructor to use.

In either case, it is a question specific to that type and a static generic class is an ideal place for storing that information.

The thing is that if you use something like MVC everything is resolved using the Type and not using a generic parameter, and then the performance decreases.

Only the first resolution is resolved using Type. If you resolve a controller that has multiple dependencies in the constructor, those dependencies are resolved generically, not through a passed type parameter.

So it performs very nice under the test conditions but in a real world scenario it is no different from the other fast containers, and doesn't have the same feature set and seems difficult (if not currently impossible) to extend with custom lifetime registrations (for example perRequest or perSession lifetimes for Web scenarios or perThread etc.).

fFastInjector is smaller than other containers and it is very compatible with different project types. In fact, I am very proud that with fFastInjector-embedded, you can add a small injector to your code by just adding a source file.

It doesn't have the same feature set as other containers because it is fairly new. This wasn't even a concept in January, when I started working on my presentation for Nebraska Code Camp on generics in C#. This project grew out of that presentation.

I am working on adding custom lifetime registrations and possibly interception to the next version.

I would recommend that the tests are change to resolve using the most basic way (using the Type and not Generics) to prevent this scenario.
Resolving using the generic parameter is only relevant if you are manually wiring everything up yourself, if you are using auto-wiring which I hope pretty much everybody prefer, then the Type is used.

I think it would be reasonable for the performance benchmark to have 2 adapters for containers that support generic resolution. One could call the generic resolver and the other could call the method with the type parameter.

Note that fFastInjector does automatically wire up concrete classes such that a call to Resolve<ConcreteClass>() will attempt to satisfy any parameters the constructor requires (by default, using the constructor with the fewest number of parameters).

If you are using the admittedly not well documented fFastInjector-MVC it can automatically wire up your controllers. It should be as simple as

ControllerBuilder.Current.SetControllerFactory(new fFastInjector.fFastInjectorControllerFactory());