使用 WCF 的 Unity 子容器生命周期
我们使用 Unity 在当前项目的 WCF 服务层内提供依赖项注入，并且我们按照如下示例编写服务主机工厂、服务主机、服务行为和实例提供程序：
http://avingtonsolutions.com/blog/post/ 2008/08/02/Uisng-Unity-with-a-WCF-Service.aspx
该解决方案工作得非常成功，但我们需要根据每个请求提供对象的上下文解析。到目前为止，我们已经通过在实例提供者的 GetInstance 方法中创建一个子容器，将上下文注册添加到子容器中，并使用子容器执行服务类型的解析来实现这一点。两个容器中的某些注册都使用容器控制的生命周期。
由于我不知道子容器的生命周期，因此我对这种方法感到担忧： 1) 子容器是否在 GetInstance 方法结束时超出范围并因此被释放，导致我们的一些容器解析对象在我们的请求中间被释放？
2) 或者，父容器是否会在一段时间内依附于子容器，这意味着在高流量环境中它会快速填满子容器实例？
有人能指出我正确的方向吗？
We're using Unity to provide dependency injection within the WCF service layer for our current project, and we have followed examples such as the following to write a service host factory, service host, service behaviour and instance provider:
http://avingtonsolutions.com/blog/post/2008/08/02/Uisng-Unity-with-a-WCF-Service.aspx
The solution works very successfully, but we have need to provide contextual resolution of objects on a per-request basis. So far, we have implemented this by creating a child container within the GetInstance method of the instance provider, adding the contextual registrations to the child container, and using the child container to perform the resolution of the service type. Some registrations in both containers use container controlled lifetimes.
As I do not know the lifetime of the child container, I have concerns about this methodology:
1) Does the child container go out of scope at the end of the GetInstance method and therefore get disposed leading to some of our our container resolved objects being disposed in the middle of our request?
2) Alternatively, does the parent container cling on to the child container for some period of time meaning that it will rapidly fill with child container instances in a high traffic environment?
Can anyone point me in the right direction?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论