C# 工作流基础4中对象上下文的管理 我使用工作流基础4和实体框架4.1。

我正在使用ReceiveAndSendReply活动集构建我的工作流。对于我来说，在每组接收和发送回复活动中使用单个ObjectContext（或者现在使用DbContext）是有意义的

---

我应该如何管理ObjectContext？是否有仅用于此目的的活动，或者我需要手动管理它？

否，没有用于此目的的内置活动

我们使用自定义服务行为和

GetExtension

，如中所示

---

不过要注意：如果您的工作流有一个隐式或显式的持久性点，那么您就不能期望上下文在这种情况下继续存在

最好不要在Workfow中直接使用DbContext或ObjectContect。将它们放在工作流扩展中，让它们为您加载POCO Entities。确保仅在Workfow中使用POCO实体，并将它们标记为可序列化。以另一种方式执行此操作肯定会导致工作流持久性和长时间运行的工作流出现问题。即使您现在不需要持久性，最好以正确的方式进行后续开发。

为什么不在工作流中使用DbContext？我知道我不能期望使用从持久性反序列化的DbContext。我以前从未使用过POCO实体，除了学习WF4之外，我真的可以不学习一个全新的microsoft东西。工作流状态中的所有内容都需要可序列化，我非常确定DbContext不是。使用POCO并不难，你甚至可以使用标准设计器和POCO生成模板。我认为Maurice的意思不是“不要在工作流中使用EF，句号。”我认为他的意思是，“不要在XAML中引用它们。”（例如，作为工作流变量）。在CodeActivity中使用EF，例如。，应该没问题。我相信因为我使用了新的DbContext，所以我的实体已经是POCO的了。因此，我仍然不清楚如何将dbContext对象公开给我的代码活动。您的意思是使用扩展，而不是为dbcontext创建工作流变量，因为它无法持久化。但是我知道，我的DbContext需要与recieve和sendreply活动之间的活动一样长，以便活动可以共享它。如何使用扩展来控制这一点？是的，您缺少工作流执行点。工作流不仅仅作为请求的一部分执行，它还可以继续独立执行。此外，即使在WCF操作期间，也没有用于存储项目的HttpContext.Current或OperationContext.Current。隐藏DbContext不是一件坏事，但恰恰相反。这是一件好事，不仅适用于长时间运行，也适用于单元测试您的活动。