我已经在我的项目中广泛使用常规的Azure Functions进行图像处理，订单处理等，并在.Net 3.1中实现它们
。 最近，我意识到使用持久函数可以很好地解决我在某些情况下遇到的问题。我在 Pluralsight 上观看了一些关于持久函数的课程，并浏览了文档和 Web 以获取一些指导和示例，但有些东西我无法弄清楚，也没有在任何地方提及。持久函数非常依赖于平台，我无法找到从业务流程协调器函数本身抽象业务逻辑的方法。
让我用一个例子来解释。假设我们有一个负责处理订单的业务流程协调器函数，它有以下步骤必须按顺序执行;检查库存，使用付款提供商向客户收费，更新库存，更新订单状态。在这种情况下，每个步骤都将是一个活动函数，我们可以创建一个服务层，将实际逻辑放在那里，并使用接口将服务层注入活动函数，并为每个活动函数提供独立于平台的代码。
我在使用这种方法时遇到的问题是，即使每个活动函数的各个步骤与平台无关，工作流本身也非常依赖于 Azure 函数，因为我们必须使用 IDurableOrchestrationContext 来实现工作流。例如，如果出于某种原因我们想从控制台应用程序调用相同的工作流，则必须再次编写工作流本身，并且我们无法保证它与业务流程协调程序函数完全遵循相同的流。此外，当我们对流程进行更改时，我们必须记住去更新这两个地方。 有没有办法克服持久函数的这个缺点，使底层代码更加独立于平台？
总之，我正在寻找一种方法来将业务逻辑与持久函数分开，并使其独立于平台。
我相信你想从 Azure 持久函数中移出业务逻辑。
在这种情况下，我认为持久任务框架是正确的选择，因为持久任务框架在single线程上运行orchestrator code。它无法与其他asyncAPI 可能调用的任何其他线程交互。
正如你所说，
工作流本身非常依赖于 Azure Functions，因为我们必须使用 IDurableOrchestrationContext 来实现工作流。
IDurableOrchestrationContext创建的task对象上的await仅由asynchronous helper methods调用，并且在技术上也可以安全地await。
只要该异步方法遵循所有正常的业务流程代码约束，调用await_myOrchestratorService.RunAsync(context);就可以很好地工作。
使用它时，ConfigureAwait(false)不要使用。否则，可能会导致MultiThreaded Execution was detected错误。
因此，DTF将不再在业务流程协调程序的上下文中考虑它。
参考此信息线程提供了与在 Azure 持久函数业务流程协调程序中使用异步帮助程序函数安全与否相关的详细信息。