Skip to content
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

Support for "proxy" relationship #1203

Closed
tillig opened this issue Sep 28, 2020 · 1 comment
Closed

Support for "proxy" relationship #1203

tillig opened this issue Sep 28, 2020 · 1 comment

Comments

@tillig
Copy link
Member

tillig commented Sep 28, 2020

In #967 it was found that decorators don't support implicit relationship types - that is, you can't have a decorator on type TService that takes in a Lazy<TService> or Func<TService> as a constructor parameter.

Based on discussion in that issue, we determined that while this seems like a use case for decorators, it's actually a slightly different type of relationship - a proxy. @sglienke put it nicely:

...the direction or order of dependencies is opposite here as it is with a decorator. With a decorator you first have T and then you wrap the decorator around it. With this case you don't have a T at that point which caused the issue in the first place. If nothing is being called you might even never have a T.

It sounds more like a new relationship where the fact that it is lazy initialized is not leaking to the consumer as it does with injecting Lazy<T>.

Given that, the answer isn't necessarily to refactor or adjust how decorators in Autofac work so much as to provide support for a new, but similar, construct that we'll call a "proxy."

This issue is to discuss and flesh out how this relationship type should work - registration syntax, resolution behavior, etc. - before diving into coding.

@tillig
Copy link
Member Author

tillig commented Nov 6, 2023

This issue has been open for quite some time without any traction. Much as we understand the challenges presented here, we also get very few substantial contributions and we don't have time to really dig into non-trivial issues like this. As such, we're closing this issue. If someone feels like they really want this, we would love to see a PR where this gets addressed.

@tillig tillig closed this as completed Nov 6, 2023
@tillig tillig added the wontfix label Nov 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant