有些东西更容易实现(代码),但有些东西通过WF更容易实现.看起来WF可用于创建(几乎)任何类型的算法.所以(理论上)我可以在WF中完成我的所有逻辑,但对所有项目来说这可能是个坏主意.
在什么情况下使用WF是一个好主意,何时会使事情变得更难？WF与手工编码的利弊/成本是什么？
什么是.Net中的依赖属性(特别是在WPF上下文中).常规财产有什么区别？
这两者之间有什么区别,何时应该使用RegisterAttached()而不是.Register()？
我一直在努力寻找一个引人注目的工作流用例(即:WF),而不是常规的命令式编程.每次我回到结论,我应该离开WF或推迟到晚些时候进入.但我一直有这种唠叨的感觉,有些东西不见了.
有谁知道任何真正为Workflow方式提供强有力理由的书？本书必须(i)很好地教授WF,以及(ii)使用适当的用例表明WF使实现变得容易,而不是我们只是进行常规的直接编码.
我会很感激的.
我正在评估WF在网络上的业务应用程序中使用,我很想听听最近这个技术的第一手资料.
我最关心的是提高项目的可维护性,并在处理频繁变化的复杂流程时提高开发人员的工作效率.
我真的很喜欢WF的想法,但是它似乎相对不为人知,而且我发现许多较老的评论都提到它一旦进入它就会非常复杂.
如果它被过度设计到一个中小型项目无法使用(或不好的权衡),那就是我需要知道的事情.
当然,它已经从2006年底开始,所以也许它已经成熟了.如果是这样的话,这是另一条非常有用的信息!
提前致谢!
使用Windows Workflow foundation(WF)与滚动自己的工作流框架有什么好处？
据我所知,WF只提供了一个非常简单的运行时引擎,一堆类和一个用于定义工作流的模式(基于XAML).所有困难的东西,如持久性,为运行时提供主机进程,以及实现分布式工作流(跨进程)都由您自己决定.
另外,使用WF还有一个学习曲线...如果我们创建了自己的工作流框架,我们只会利用所有开发人员已有的技能(C#,XML,SQL等).
我从MS传播者那里看到了这个博客,它试图解释为什么我们应该使用WF:
IMO它没有很好地说服,因为它只是说它有助于"开发人员的工作效率",同时承认开发人员可以自己动手.
任何一个聪明的人都可以提出更好的理由吗？
以下答案摘要:
我认为最有说服力的理由是使用标准化的工作流平台(如WF(而不是自己动手))将允许您利用当前和未来的工具,例如MS和第三方提供的可视化设计器.
另外,因为它是基于.NET的技术的MS堆栈的一部分,它可能会有更好的集成/迁移路径与未来的MS技术(如Azure).
最后,拥有WF经验的开发人员数量将会增加(因为这将使他们在职业生涯中受益),将其转变为基本的商品技能,如SQL或HTML,这意味着找到可以开始使用它的人变得更容易最小的加速时间.
这是一个多部分问题:
首先,您对Workflow的个人看法是什么？
其次,有没有其他好的基于.NET的工作流引擎？有关我用法的一些信息:
我不关心工作流是在DB,XML还是Code中定义的,因为我们决定定义它,如果它不受支持,我们可以编写一个适配器.专有(免费或费用)很好,但首选开源.
我开始认为我应该抛弃Windows WF而不是更简单的东西.我不一定需要在很长一段时间内暂停工作流程执行并在以后恢复它们.但是,我想要一个简单的状态机框架,它具有基本的挂起/恢复/中止(没有序列化).
我已经从Google Code下载了无状态框架,我将开始玩它,但是很想听听其他.NET程序员使用的内容.
编辑无国界似乎很容易实现,但我想知道它是否适合糖果机.在自动化中,我总是对如何使用状态机感到矛盾.虽然我使用术语"状态机",但我这样做很松散,因为我更像是一个流程图.我没有使用状态来表示机器所处的当前模式,而是使用它来执行函数.所以在这种情况下使用Stateless,我实际上是使用从一个状态到下一个状态的转换作为在我的糖果机控制器中调用函数的机制.思考？
我想了解"状态机"和"工作流程"之间的区别,它与"状态机工作流程"有什么不同？
business-process-management state-machine workflow-foundation
我目前正在搜索适用于.NET的规则引擎.我们的逻辑很简单,+, - ,*,/,和/或基本的操作顺序.但是,我们需要将此信息存储在数据库中,然后在从数据库中提取新版本时生成规则文件.因此,除非其中一个具有Web版UI编辑器,否则常见的UI编辑对我们来说将毫无用处.
所以我的问题是,鉴于我所说的,在编程配置和与ASP.NET集成方面,这将是我们最好的规则引擎.