Diagnose Fallback / Facade Container problems and find better implementaion

Issue #270 resolved
Maksim Volkau
repo owner created an issue

List of problems:

  • [#247]: Collection wrapper resolved from Facade does not count parent container registrations
  • Singleton resolved in fallback container is not used by facade
  • [done] Weak referencing the fallback container is the only mechanism now

Considerations:

  • Resolve fallback services as resolution call to fallback container instead of inline expression. It will require to represent (don't erase) fallback container in generated expression

  • Fallback / Facade container feature caused the split of IScopes from IContainer, so that IContainer may be swapped independently in Request to fallback container. It will be great to fix this, to simplify the code

  • Keep single Parent / Facade container with resolution implemented as Resolve call, and remove the rest of Fallback Containers, or at least remove them a entity from the Rules

Use profiles #309

To provide the desired funcionality

Another idea

Make the Facade an updated original container with the special rules:

  • The default registration "replaces" any number of default registrations in original
  • The keyed registration into Facade "replaces" the registration from original, if any
  • The singletons are chained so that: original singletons are resolvable from facade, but facade singleton are separate and disposed without touching the originals
  • Resolving many has two options: a) combine both facade and original registrations possibly producing multiple same key services. b) Override default with facade default and keyed with facade keyed registrations

Update 2017/09/18

Removing the FallbackContainers alltogether, and replacing CreateFacade implementation with:

 With(rules => rules.WithFactorySelector(Rules.SelectKeyedOverDefaultFactory(FacadeKey)));

Hope, that 99% cases may be solved this way, or with combination of other Container methods like WithoutSingletonsAndCache()