Support composite pattern via decorators/proxies

[ashmind]

I've started building a RegisterComposite extension (same as #297), and I run into a few things that could be done better if I had more access to Autofac logic.

For example, it would be useful to be able to reuse logic behind CollectionRegistrationSource instead of doing this manually.

My suggestion: either make CollectionRegistrationSource public and support a filter delegate or a virtual method; or expose IsGenericListOrCollectionInterfaceType and similar through a public helper.

[tillig]

We'll have to think about this. Not sure if it'll make it in soon or not. The problem with opening internals up is that, basically, we're then stuck with them public as part of the supported API forever. Even if we stop using them and go a different route, we can't just refactor and remove anymore.

I'll leave the issue open, but for now your best bet is to go the copy/paste route.

[alexmg]

I'm interested in improving our decorator support and catering for the composite pattern aligns with that. I would be interested to see what your implementation would look like if you could make the changes you are proposing. Perhaps this is something you could do in a fork that I could reference?

[ashmind]

@alexmg That's interesting -- I only considered superficial changes here to help reuse some code, but proper integration would look different.

In my current solution:

1. You register multiple implementations of ISomething.
2. You register a composite (I use RegisterComposite<> at the moment, but I'm now thinking it should be AsComposite<> instead).
3. You can register more implementations after 2, but those need PreserveExistingDefaults.
4. When you Resolve<ISomething> you get the composite (since it's the default), which uses a hacky Parameter override to avoid circular dependency.
5. When you Resolve<ISomething[]> you get a mess (all implementations from 1 and 3, plus the composite).

In a perfect solution as I see it:

1. You register multiple implementations of ISomething.
2. You register a composite.
3. You can register more implementations. Probably without needing PreserveExistingDefaults, since e.g. a plugin assembly wouldn't know there is a composite. But then it would need some other marker to override composite if it explicitly wants to.
4. When you Resolve<ISomething> you get the composite (resolution should be done without weird parameter override — by having some hook between finding registrations and resolving them).
5. When you Resolve<ISomething[]> you get an array with a single item — the composite.

I'll take a look at what's needed to change for a perfect solution, but I can't promise any specific timeline. Hopefully later this week.

[tillig]

Since the overall goal of the thing is to get composite support in, I've updated the title here.

We're pushing to enhance decorator syntax and features, which will hopefully resolve this issue. I've created a larger meta-issue for tracking that at #880. In the meantime, I'll close this specific issue and hopefully we can handle everything at once.