-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parent child container support for Dip #171
Parent child container support for Dip #171
Conversation
@john-twigg-ck thanks for your work! |
@ilyapuchka @jtwigg and @john-twigg-ck are in fact the same people! Sorry for the confusion. I launched this PR from our corp account. It does solve the problems I had with collaboration. |
I thought so 😂 |
@ilyapuchka I'll try and maintain come consistency here from this account. So thats great news that you are in favor of the change. If you want to deprecate collaboration then a few points need to be discussed
should actually be
since context shares the lifecycle of the resolve() call and resolvedInstances shares the lifecycle of the container (good for singletons). ** Thoughts?** |
I'll be able to get back to this and really discuss this only on a weekend, unfortunately, so keep this thought =) |
@ilyapuchka Awesome. Thanks for merging. |
Support for Parent Child containers
First off, I have to say I love Dip, and you've done an amazing job at the API. I heavily vetted Dip along with Swinject, Cleanse and a few other containers. I've used Unity .Net for over a decade, Guice for years. But yours was perfect for us especially around syntax.
Motivation
This PR takes its inspiration from (Dagger Subcomponents)[https://google.github.io/dagger/subcomponents]
The motivations is to provide support for Container to have a hierarchy, such that some containers can be denoted as Parent containers and others as Child and sibling containers.
Child containers will be isolated from each other, and parent containers will be isolated from the child containers.
Rules
Changes to existing behavior
Much effort was made to maintain and only extend the existing behavior, however there were knock on effects with respect to resolving ambiguities that I believe are an overall improvement, making resolution more deterministic and easier to reason about.
Attached is a screenshot of a Unit Test I added before/after this change that focuses on Collaborators.
Before: I believe the collaboration of the containers prior to this change were somewhat ambiguously resolved. In the example resolving the dependency from either collaborated container would bias the results towards the container that contained the AutoWire. In fact order of associating collaborators can have a big impact on the results.
After: With the addition of the behavior that all nested resolves are reinitiated with the originating container, I believe the behavior is now more deterministic and predictable. In this example, the container2 has registered a SerivceImpl2 under its Service protocol. When you resolve using conatiner2, anything requesting a Service will receive a ServiceImpl2 implementation which seems reasonable since you just went to the trouble of registering it and requesting it.
Further Improvements
Perhaps we should restrict the mixture of collaboration and parent child relationships.