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 multiple types using same Interface with same generic parameters? #640

Open
Xylotomous opened this Issue Dec 6, 2018 · 3 comments

Comments

2 participants
@Xylotomous

Xylotomous commented Dec 6, 2018

Hello, I tried for two days to find a solution before resorting to asking a question (ergo, using your valuable time). I'm not able to use Stackoverflow due to corporate situation but github, yes.

I have this interface: IQueryHandler<aDTO, IEnumerable<aDTO>> where the aDTO serves as both an input (carries IDs in) and an output (carries other IDs out, often as a list of unique ones in a aDTO instance).

I have numerous classes which take this as a constructor parameter

public SomeDataClass(IQueryHandler<aDTO, IEnumerable<aDTO>> dao)
{
    _dao = dao;
}

Any attempt (tried many ways) to register the consumer classes fails as only one registration will stick and the others are skipped I believe. Then at the injector verify stage it fails because the skipped ones aren't registered.

I believe this is because Simple Injector is saying it can't know what implementation to return because there are many that match the interface? I've tried registering a collection but this fails, and numerous other means from the SI docs but it always fails. Unfortunately, I have little control over the consumer classes (in a lib someone else wrote, can't be changed) only the host application (web app).

This kind of Interface (the IQueryHandler) is pretty common in my experience so I'm wondering if there is a way to make this usable. My thought is some SI ability to use a factory IN the SI configuration to resolve the type to the correct implementation of IQueryHandler. Thinking that SI knows the class is asking for the type so I could use that to give it the correct implementation even if I have to define it by way of if/else or switch. If it's not possible I'll have to try and argue another DI container if I Can find one that supports this! Otherwise, I'll have to contrive some manual factory or some such to stitch up the graph. :-(

Thanks you so much for your precious time. I really tried to avoid this.

@dotnetjunkie

This comment has been minimized.

Collaborator

dotnetjunkie commented Dec 6, 2018

Please post a MCVE. I would like to see:

  • Your IQueryHandler interface
  • Some sample implementations
  • Your registrations
  • A consumer implementation
  • Some sample code that executes that consumer
  • The exception message + stack trace.

Please don't link to a Github repository with a solution, but post the minimal code possible that reproduces the problem, while being complete (it can be copied into an IDE and compiled).

@Xylotomous

This comment has been minimized.

Xylotomous commented Dec 6, 2018

Thank you for the quick response, I'll do as you requested and post asap.

@Xylotomous

This comment has been minimized.

Xylotomous commented Dec 7, 2018

Hello, ultimately I was able to force one of the library developers I depend on to allow injection of a collection. Also Register.Collection is working now (there was another subtle problem not caused by Simple Injector) and that has allowed the initial case of multiple interface implementations with the same parameters to register properly. I came up with a means to identify the correct instance from the injected collection without using reflection.

Neither injecting a collection or going the factory route is preferable, but given you can't inject something that is ambiguous to Simple Injector because it cannot know which implementation, there must be compromise. There are too many parts and too many developers to revisit the larger design to something that would not require this in the first place so such it shall be.

Thank you for your precious time and a very deep thanks for sharing your brilliant tool with the community. I fought hard to use SI over other libraries as I firmly believe it's the best one out there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment