Support for Other IoC Containers

Hi all,

Is there any idea about supporting other ioc libraries that popular, fast and meets the requirements as much as Castle Windsor? Such as DryIoc, SimpleInjector, LightInject etc…?

There is a comparison about Ioc Benchmarks and features, as far as i learned from comparison; some of ioc containers have Interceptors, auto wiring, custom life time and so on, that features already used by Abp. See: Ioc Benchmarks and Comparisons

For Ex; Let’s say; If there is an abstraction in CompositionRoot; when we initialize via

IContainer dryIocContainer = new Container();
var bootstrapper = new AbpBootstrapper();
bootstrapper.UseDryIoc(dryIocContainer);
//bootstrapper.UseNinject(ninjectContainer);
//bootstrapper.UseSimpleInjector(simpleInjectorContainer);
bootstrapper.Initialize();

And of course generic IocManager<T> based on container interface. Such as:

IocManager<IWindsorContainer> //Castle
IocManager<IContainer> //DryIoc
IocManager<Container> //SimpleInjector

IMHO, It might be useful for who wants to use other ioc frameworks.

What do you think about this idea?

Thanks.

[hitaspdotnet]

@hikalkan Is there any update? or moved to newer I want use Autofac in my project (Zero Template). Isn’t possible now?

[osoykan]

Hi All,

There are some things need clarification.

Autofac is most popular and new generation DI container. Which is also considered as modern way to dependency injection by some of communities If compared other DI containers such as Windsor, StructureMap so on…

If any support is provided to new DI container, it definetely should be Autofac. But… Abp’s kernel precisely depends runtime registrations. What does it mean? So, Abp’s Module system has three void methods that PreInitialize, Initialize, PostInitialize. So, we are currently registering and resolving components while project’s bootstrapping time. That means we have a Castle Container that has been built before(internally) and we’re adding new services to it. Windsor provides this feature to us nice way.

But, in Autofac these things don’t work like that. If an Autofac container is built, then you absolutely can’t add any services to it. The only way to do is that create a new temproray Container and update existing container with your temproray container. We could say or assume that container-knowledge exchange.

So, approximately one month ago this Container Update operation marked Obsolete, it would be removed in a few year. Thus, in my opinion, we can’t port to Autofac or something similiar DI containers because of our Abp habits.

Discussion: Autofac ContainerBuilder.Update Marked Obsolete https://github.com/autofac/Autofac/issues/811

Autofac Contributos Say:

Note that part of what we’re trying to do is not only provide a good container but push people towards better practices and help them avoid pitfalls. Bringing over practices from one container to another isn’t something we’re really interested in addressing since each container has its own quirks. On the other hand, it is interesting to provide a good feature set; get people to use good IoC practices that avoid container inconsistency; and be able to bring the container forward by adding new features.