WF 和 WPF 交互的真实示例

发布于 2024-10-17 16:22:10 字数 178 浏览 2 评论 0 原文

我正在寻找一些有关 Windows Presentation Foundation 和 Workflow Foundation 之间交互的真实示例。我看到的大多数 WF 教程都演示了在控制台应用程序中的使用。我对使用丰富的 WPF 界面和 WF 的应用程序更好奇。特别是如果它们允许用户定义的工作流程（允许用户动态设计和运行自己的工作流程）。

原文

分享到QQ

分享到微博

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

发布评论

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

花期渐远 2024-10-24 16:22:10

我不确定您到底在寻找什么，但这里有一些链接，指向有关以某种方式在桌面 (WPF) 应用程序中使用工作流的实际应用程序的信息：

现实世界 WF4 集成示例
Infinity Workflow （链接中包含大量信息 Word 文件)
Aderant 企业工作流程（也可在 PDC Windows Workflow Foundation Futures 会话)

回复收藏 0 原文

浪菊怪哟 2024-10-24 16:22:10

让我举一个尝试让两个工作流程相互通信的例子。

首先您需要编写一个主机。这是一个非常繁重的命题，因为要使两个 WF 主机相互通信，您还需要了解 WCF 以及所有模糊的线程概念。
然后您的 WF 将需要通过主机与其他 WF 进行通信。这是有道理的，因为当 WF 等待另一个 WF 发送事件时，它不会在内存中保持运行 3 个月。 WF 位于数据库中，并且通过主机进行通信。
好的，即使对于更简单的场景，对于本地进程内通信，您也有 CallExternalMethod 活动和 HandleExternalEvent 活动。即使在这种情况下，您也必须通过主机进行通信，因为 WF 可能已对数据库进行钝化。因此，为了做到这一点，您必须记住做三件事，用ExternalDataExchangeAttribute装饰您的界面，eventargs需要从ExternalDataEventArgs派生，并且事件args是可序列化的。
如果你搞砸了 #3 中的任何一项，你会得到一个非常不直观的“InvalidOperationException”。当然，该消息说“服务未实现具有ExternalDataExchange属性的接口”，但直到您查看内部异常，您才真正知道发生了什么 - 即您忘记使其可序列化。哦！但我确实将其标记为可序列化。实际上，一切都需要可序列化，即使是发送者。
然后，您必须通过用于通信的正确接口名称和方法名称来连接 WF 活动。
最后，即使对于进程内 WF 通信，您也必须记住将服务添加到ExternalDataExchangeService，而不是WF 运行时。否则，看起来好像没有人订阅该活动。更不用说，这是其中一个错误，它并不会真正引发错误。即很难追踪！

因此，简而言之，对于尝试使两个工作流程进行通信的简单场景，您需要很好地处理以下内容：

*编写 Windows 应用程序（针对主机），
*螺纹加工，
*WCF，
*面向对象编程的概念，
*序列化的所有概念，
*WF 本身有大量的连接和非直观细节，
*忍者调试技巧。

来源：http://blah.winsmarts.com/2008-2-I've_been_here_before.aspx

Let me take the example of trying to make two workflows communicate with each other.

First you need to write a host. This is an extremely loaded proposition, because for two WF hosts to talk to each other, you will then also need to know WCF, and all mushy concepts of threading.
Then your WF will need to communicate with other WFs via the hosts. This makes sense because a WF doesn't keep running in memory for 3 months, when it is waiting for another WF to send an event. The WF sits in the database, and the communication occurs through the hosts.
Okay, even for simpler scenarios, for local in-process communication, you have the CallExternalMethod activity, and HandleExternalEvent activities. Even in this case, you have to talk via the host, because the WF might have been passivated to the database. So in order to do so, you have to remember to do 3 things, decorate your interface with the ExternalDataExchangeAttribute, eventargs needs to derive from ExternalDataEventArgs, and event args is serializable.
If you mess up in any of the items in #3, you get a very non-intuitive "InvalidOperationException". Sure the message says, "Service does not implement an interface with the ExternalDataExchange attribute", but it isn't until you look at the inner exception, that you really know what happened - i.e. you forgot to make it serializable. doh! But I did mark it as serializable. Actually, everything needs to be serializable, even the sender.
Then you have to connect the WF activities, via the proper interface names and method names you are using to communicate.
Finally, for even in-process WF communication, you have to remember to add your service to the ExternalDataExchangeService, and not the WF runtime. Otherwise, it will look like nobody is subscribing to the event. Not to mention, that this is one of those bug, that doesn't really throw an error. i.e. hard to track down!

So, in short, for the simplistic scenario of trying to make two workflows communicate, you need to have a good handle on the following:

*Writing windows apps (for the host),
*Threading,
*WCF,
*OOP Concepts,
*All concepts of serialization,
*Plenty of hooking up and non-intuitive details of WF itself,
*Ninja debugging skills.

Source:http://blah.winsmarts.com/2008-2-I've_been_here_before.aspx

回复收藏 0 原文