-
-
Notifications
You must be signed in to change notification settings - Fork 27
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
Register / Resolve T or IEnumerable<T> #124
Comments
@dansiegel Likely you'll need rules.WithFactorySelector(Rules.SelectLastRegisteredFactory()) instead of Here is the docs: https://github.com/dadhi/DryIoc/blob/master/docs/DryIoc.Docs/RulesAndDefaultConventions.md#resolving-from-multiple-default-services |
perfect... that does indeed solve the issue. Thanks @dadhi |
@dadhi sorry to keep bugging... As was being discussed in @dahlbyk's PR... there is a related issue here that in another place we have a check for IsRegistered... Since we assume IsRegistered should return true whether we are checking for T or IEnumerable. The following change was proposed, but I'm not sure if this is ideal or if it can be simplified. return Instance.IsRegistered(type) ||
Instance.IsRegistered(type, factoryType: FactoryType.Wrapper); Also in further testing I realized that we do have an issue with keyed services not appending... is there a way to get keyed services to append instead of throwing? The only work around I've found there is to force a Replace for keyed services |
Yes, for keyed this is the only way I imagine at the moment, because the keyed services are supposed to be unique.
IEnumerable wrapper is always registered whether or not you are registered a service type, so that the enpty collection will be returned for the non registered type. |
Thanks @dadhi... we could certainly check if it's an |
Since DryIoc supports resolving a few different collection types (everything implemented by Is there a downside to checking if a wrapper is registered for the specified type? Expected behavior for resolving a collection for an unregistered type is an empty collection, which seems consistent with considering |
It is correct. Plus its own
No downside I am aware of. That way you will check for whatever wrapper suported by DryIoc. |
fixed by #126 |
Description
As initially discussed in issue #115 we have an issue where IEnumerable may need to be resolved. This is a particular issue with Shiny integration where multiple delegates may be registered and will need to be resolved.
Problem
Prism registers services with an expectation that we will internally only want to resolve the last registration for any particular service. However it is possible for developers, or 3rd party plugins such as Shiny to require registering multiple services as is the case for Delegates. In this scenario it would be normal to see:
Expectations
What we need is a proper ruleset for the Container so that:
Resolve<ISomeDelegate>()
we should getDelegateB
Resolve<IEnumerable<ISomeDelegate>>()
we should get back a collection with bothDelegateA
andDelegateB
.Observations
Currently we use the default
IfAlreadyRegistered.Replace
, this satisfies the first requirement, but fails on the second as we only get a collection with DelegateB.If we do not set the IfAlreadyRegistered behavior or set it explicitly to Append, we succeed on the second requirement but fail on the first.
cc: @dadhi... any thoughts?
The text was updated successfully, but these errors were encountered: