Most natural way to achieve these is through a module, but this isn't as discoverable. May consider merging Container and ContainerBuilder yet again, but this takes us back to either having endlessly mutable registrations, or having a syntactic terminator in the registration DSL.

Ummm... what about OnlyIfNotRegistered() (instead of DefaultOnly()?)

Transparent Decorators

One cool thing that is enabled by the availability of component ids (separated from their names) is that a decorator can assume the name of the decorated component and still retrieve instances of the decorated component by its id.

E.g. in a container where names are ids, you have to call the decorated component something different, like "real-thingy" and then call the decorator "thingy". This requires some forethought and doesn't give you the option of decorating something that was configured inside a programmatic module.

In Autofac you should be able to say 'decorate thingy' and have the configuration code find the id of the component with the name "thingy" so that the decorator can assume the name "thingy" while still referring to the old component by id. Nice and transparent.

First class decorator support in the API seems like a good thing. E.g. builder.Decorate<IFoo>(foo => new DecoratedFoo(foo)). To do this well, either the original component's activator would be decorated, or the additional decorator component would need to have the same scope (sharing) as foo. Next item addresses an issue currently holding that back.

Eliminate/Hide IScope

The extension point that allows traditional per-thread or per-request sharing is not being used. Removing/hiding it and promoting the InstanceScope enum to the core API will make it easier to reason about registrations reflectively (i.e. instead of downcasting !IScope, compare enum values.)

Use Configured Reflection Activator when doing Property Injection

E.g. see issue 62.

Optimise Reflection Activator when Suitable

Autofac doesn't cache constructor searches in order to behave correctly in light of dynamic registrations. Many components will use the same ctor throughout an execution, so perhaps:

builder.Register<Foo>().WithCachedActivator();

Comment by nicholas.blumhardt, Jun 30, 2008

Consider merging Autofac.Builder namespace into Autofac namespace? ContainerBuilder? into container?

Comment by mads4988, Jul 01, 2008

It would be great if RegisterGeneratedFactory? could be made available in .net 2.0.

The ability to set properties directly on the type being injected to avoid using strings to define property names would be nice. Maybe something a bit like this?

builder.Register<IFoo>().WithProperties?(delegate(IContext c, IFoo target) {

target.Bar = c.Resolve<IBar>(); target.Bar2 = c.Resolve<IBar2>();

});

//...

container.InjectProperties?<IFoo>(foo);

Handling InjectPropertiesIfUnset? would be a little less trivial.

Comment by nicholas.blumhardt, Jul 05, 2008

Hi Mads,

What you've described is already available, though it could be improved.

If you're using delegate activators, you just set properties on the instance before returning it from the delegate (strong typing.)

If you're using the reflection activator, you can still do this by handling the OnActivating? event:

builder.Register<Foo>().OnActivating?((sender, e) => {

((Foo)e.Instance).Bar = Baz;

});

Equally strong typing, the cast is an unfortunate syntactic artifact but is necessary at least through the base API. An OnActivating?<T> overload would ease this up.

Comment by ralf.warnat, Sep 02 (4 days ago)

I vote for XML Configuration Enhancements with some array-element-syntax maybe inside a property:

<property name="MyCollection">
   <components> <!-- ...  --> </components>
</property>

and referencing other previously registered components.