You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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 aLazy<TService>
orFunc<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:
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.
The text was updated successfully, but these errors were encountered: