解析类型时是否可以更改配置的生命周期管理器？
我将 Unity 配置为能够使用我自己的生命周期管理器（每个 http 请求）解析多种类型。现在，在一种特殊的初始化方法中，我需要获取已解析类型结构的新实例，并且我不希望存储这些实例并重用于后续的 Resolve 调用 = 对于这种特殊方法，我需要瞬态生命周期管理器。
我想避免第二个容器配置，因为它将是具有不同生命周期管理器的第一个容器的副本。解析类型时是否可以以某种方式覆盖生命周期管理器配置？
这个问题与我的上一个问题有关，因为我正在寻找更好的方法这样做。
编辑：
我知道我可以创建多个命名注册，但是仅仅因为更改生命周期管理器，就需要再次创建大部分配置。
I have my Unity configured to be able to resolve several types with my own lifetime manager (per http request). Now in one special initialization method I need to get fresh instances of resolved types structure and I don't want these instances to be stored and reused for subsequent Resolve calls = for this special method I need transient lifetime manager.
I want to avoid second container configuration because it will be copy of the first one with different lifetime managers. Is it possible somehow override lifetime manager configuration when resolving the type?
This question is realted to my previous question because I'm looking for better way to do that.
Edit:
I know that I can create multiple named registrations but that whould require creating big part of configuration again just because of changing lifetime manager.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以使用子容器来进行特殊解析。只需在子容器中为您关心的类型注册一个新的生命周期管理器（TransientLifetimeManager 听起来像您想要的）。它将从父级获取其他所有注册，因此您无需重做大量注册。
但我同意阿利斯塔德的观点——这个设计闻起来不对，但如果没有更多关于你正在做的事情的细节，我真的不能建议一个替代方案。
You could use a child container for the special resolve. Just register a new lifetime manager (TransientLifetimeManager sounds like what you want) in the child container for the types you care about. It'll take the registrations from the parent for everything else, so you don't need to redo massive chunks of registration.
But I agree with Aliostad - this design smells wrong, but without more details of what you're doing I can't really suggest an alternative.
我认为 - 正如您所指出的 - 我们可以使用两个单独的注册和两种不同的生命周期配置。但您似乎对此设置并不满意，并且希望在注册时就过掉生命周期。
我的建议是创建一个扩展方法，该方法需要额外的生命周期并检查容器是否存在此类注册，如果不存在，则会注册它并返回您所需的设置。
但说实话，我对这种方法确实有问题，即使框架中存在这样的方法。 IoC 容器删除了依赖项对依赖项的了解，但您将此知识添加回客户端/依赖项，这违反了 IoC 原则。
I think - as you have noted - we can use two separate registrations with tow different lifetime configurations. But you seem not to be happy with this setup and you would like to pass the lifetime at the time of registration.
My suggestion is to create an extension method which takes an additional lifetime and checks the container for such registration and if it does not exist, it registers it and returns with the setup you require.
But to be honest, I do have a problem with this approach, even if such a method existed in the framework. IoC containers remove the knowledge of the dependant on the dependency but you are adding this knowledge back to the client/dependant which against the IoC principle.