.net 4.0 工作流基础4的思考与体会 现在微软已经在Windows工作流基础4中修改了他们的工作流框架，你对这个新的框架有什么想法和经验？

我使用WF4已经有几个月了，我遇到了一些陷阱：

• 没有办法强制使用工作流服务（Xamlx）接口
• 当工作流中发生错误时，无论是通信、关联、持久性还是工作流中未处理的异常，都几乎不可能判断出问题所在，因为跟踪日志没有告诉您任何相关信息。例如，我有一个实体框架对象作为工作流变量，工作流持久化在序列化它时遇到了一些问题。不幸的是，跟踪文件中没有任何错误表明这就是问题所在。我经历了好几个小时的反复试验，才知道出了什么问题
• 提供的一些活动是不够的。例如，我必须扩展Send活动以支持动态端点。不幸的是，我不能使它完全动态，例如，接口名称不能是动态的
• 如果工作流变得太大，则设计器会变得非常慢。一个大小超过100KB的工作流加载时间超过一分钟！忘记调试这样大小的工作流
• 没有针对Oracle的持久性提供程序

尽管存在这些缺陷，但数据库的持久性功能、在设计器中轻松地将活动捕捉到一起以及轻松地将WCF服务设置为工作流服务给我留下了深刻的印象

我对使用工作流基础4的其他开发人员的体验感到好奇。

编辑：

我能够解决大型工作流的设计速度极慢的问题。事实证明，存在无法解决的导入，这显然给设计师带来了很大的压力

更新

---

现在我们已经投入生产，AppFabric面临着一系列问题。我很清楚，到目前为止，AppFabric工作流服务还没有准备好使用。在新版本发布之前，我不会这么做。

我在工作流中也遇到了异常问题，主要是确定异常发生的原因、来源以及描述或消息。随着经验的积累，我在这方面做得更好，如果我开始另一个工作流项目，我将能够更高效地调试它。这只是一个不同的范例，因此不能以与直接代码相同的方式进行处理

我在WF4.0中遇到的另一个问题是使用

WorkflowInvoker

进行单元测试；这些细节让我无法理解，但模仿依赖关系和父/子工作流确实令人头痛

---

一般来说，我真的很喜欢WF4.0，它比3.5有很大的改进。在调试模式下运行可能会非常慢，在设计器中调试会非常麻烦，但该框架非常好，非常有用。

我认为您对WF4问题做了一个非常好的总结

---

我的主要痛点是无法更改进程内工作流的定义。这一问题在下一个版本中得到了解决，但目前这是一个大问题。

我可以理解，您可能希望更改进程内工作流的定义，但这似乎是一个逻辑上的不一致之处—就像在执行过程中更改类定义一样。我应该做一些解释，但答案不是在“旧”工作流结束时同时运行“旧”定义和“新”定义吗？有什么好的链接可以解释问题吗？工作流只是代码的另一部分，可能包含bug。有时候你真的需要修复这些bug，而不是任由它们出现。查看Rin Jacobs的WF futures会话了解更多信息我还面临windows workflow 4.5中实体对象（实体框架）变量的持久性问题。您能告诉我们您对此持久性问题采取了什么方法吗？我们的方法是从不使用实体对象作为工作流变量或参数。我们总是将其转换为内部数据对象。您可以使用实体作为变量或参数。您只需确保实体已分离。我猜我们的问题是我们从数据库中提取了一些实体，但仍然附加到一个不再存在的上下文。在WF persist上，它尝试序列化实体及其引用，但由于上下文不再存在，因此无法查询这些引用。如果你想在工作流中持久化实体，你必须小心。谢谢。我们遵循了您概述的类似方法。我们最终没有使用实体框架对象，而是使用自定义poco对象。