Unity 不尊重 TransientLifetimeManager?

发布于 2024-10-15 02:44:49 字数 1033 浏览 6 评论 0原文

我有以下场景:

一个 WCF 服务解决方案,包含服务实现层、业务层和数据层。 WCF实现层依赖于业务层,业务层又依赖于数据层。每层通过构造函数注入接收其依赖项。我们使用 Unity 将这一切连接在一起。我们有一个自定义的 WCF 服务主机/因素/行为/实例提供程序,它调用我们的 Unity 容器来解析要使用的 WCF 服务及其各种依赖项。

它工作得很好......几乎。

我们首先在数据层中使用 EntityFramework 代码。我们看到的是,在首次调用 WCF 时创建了一个新的 DbContext 类,但该类在后续调用服务时会重用。当我们的服务为同时访问数据库的多个调用提供服务时,这当然会成为一个问题。通过在 DbContext 类的构造函数中放置一些跟踪语句,我能够证明 DbContext 类实际上被重用。我进一步沿着链向上,将类似的跟踪语句放置在业务层实现构造函数中,发现这也只被调用一次。事实上,似乎在每个服务调用上仅构建 WCF 服务实现,并且数据层和业务层表现为单例。

据我所知,在 Unity 中使用 RegisterType 时,听起来默认行为是使用 TransientLifetimeManager,这意味着每次调用都会创建一个新实例来解决。由于此默认行为似乎无法正常工作,因此我们尝试将生命周期管理器显式设置为 TransientLifetimeManager,但是我们仍然看到业务层和数据层表现为单例。

关于我需要做什么才能让我们的 WCF 依赖项表现得像单例,有什么想法吗?

更新:仍然没有成功。我尝试使用 PerResolveLifetimeManager,但这并没有解决问题。作为临时解决方案,我重构了代码,以便将工厂注入到我的数据层中。工厂提供了 DbContext 实例,因此我能够确保对数据层的每次调用都使用新的 DbContext。目前工作正常,但我想解决导致 Unity 在创建实例后保留并重用实例的任何问题。

I have the following scenario:

A WCF service solution that contains a service implementation layer, business layer and data layer. The WCF implementation layer depends on the business layer and the business layer on the data layer. Each layer receives it's dependencies via constructor injection. We've wired this all together using Unity. We have a custom WCF service host/factor/behavior/instance provider that calls into our Unity container to resolve the WCF service to use and it's various dependencies.

It's working great...almost.

We're using EntityFramework code first in our data layer. What we're seeing is that a new DbContext class is created on the initial call into WCF, but that class is reused on subsequent calls into the service. This becomes a problem of course when our service is serving multiple calls that are accessing the database concurrently. I was able to prove out that the DbContext class is in fact being reused by placing some trace statements in the DbContext class' constructor. I went further up the chain and places similar trace statements in the business layer implementation constructor and found that this is also only being called once. In fact, it appears that only the WCF service implementation is being constructed on each service call and that the data and business layers are behaving as singletons.

From what I've read, it sounds like the default behavior when using RegisterType with Unity is to use the TransientLifetimeManager and that this implies a new instance will be created on every call to Resolve. Since it didn't appear that this default behavior was working correctly, we tried explicitly setting the lifetime manager as TransientLifetimeManager, however we're still seeing our business and data layers behaving as singletons.

Any ideas on what I need to do to get our WCF dependencies to behave as singletons?

Update: Still no success. I tried using the PerResolveLifetimeManager, however that did not solve the problem. As a temporary work around, I refactored my code so that it's injecting a factory into my data layer. The factory provides DbContext instances, so I'm able to ensure that each call into my data layer is using a new DbContext. This is working ok for now, but I'd like to resolve whatever issue is causing Unity to hold onto and re-use instances after they're created.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

扛起拖把扫天下 2024-10-22 02:44:49

我们使用的方式:

  1. 我们向 HierarchicalLifetimeManager (和其他服务)注册我们的 DbContext。
  2. 在 WCF 实例中,我们创建新的子容器并从此(子)容器解析服务。
  3. 使用 [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)] 标记服务

因此,HierarchicalLifetimeManager 的魔力为我们提供了新的服务实例以及每个请求的所有相关数据。

The way we use:

  1. We register our DbContext with HierarchicalLifetimeManager (and other services).
  2. In WCF instance provide we create new child contriner and resolve service from this (child) container.
  3. Mark service with [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]

So, the magic of HierarchicalLifetimeManager gives us new instance of service and all related data for every request.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文