.NET WF4:它应该在一切的中间吗？

Question

我正在研究一种基本上是n层协作应用程序的新架构(不是企业级,只是一个有可能大幅增长的小项目),我已经在努力训练自己使用IoC,在某种程度上, TDD,我想知道,一般来说,只是手工编写工作流逻辑是否明智,或者我是否应该深入学习和整合WF4(Windows Workflow 4.0,.NET 4.0的一部分),以便WF成为字面意思整个应用程序的控制器,即"MVC"中的实用C(不是ASP.NET MVC,而是模式).那么WF4中的工作流活动是否应该成为高度可扩展/可扩展的基于Web的协作应用程序的主要控制器？或者我问完全错误的问题？

这是一个模糊的问题,我敢肯定,所以抽象的答案和特定的答案一样受欢迎.

我知道WF4是对WF3进行重大改造和重新设计的地方,WF3在WF4中已经清理了很多使WF3成为糟糕技术选择的东西.例如,据我所知(虽然我看起来并不是很努力,而且几乎没有对此进行报道),WF4活动或多或少可以通过[TestMethod]和嘲弄来测试(有人知道请确认？WF的可测试性对我们来说是一个巨大的问题).我对使用WF的XML图表或后期加载很感兴趣,我更喜欢编写具体的C#工作流声明,但如果工作流可以用编译语言简洁地编写并且可以测试,我很想付钱注意它.因此,如果有这些改进,其他诸如改善性能之类的技术再次引起了我对该技术的关注,而我之前曾对WF3进行过嘲讽.

此外,根据微软的说法,WF4是微软希望在未来使用MS CRM,MS SharePoint等不同工作流技术的经验教训后,为所有众多工作流程驱动的产品实现标准化的目标.我当然对赌博感到好奇一个通用的功能,但只有实现可以简洁,在编译时进行类型检查,可测试和可维护.

编辑:只有那些知道WF4(而不是WF3)的人的答案才会被认为是"答案".

Answer 1

不，我不会把它放在所有事情的中间。

我目前正在参与一个广泛使用工作流程 3 的项目。它不是工作流程 4，我知道 WF4 有很多改进，但是...工作流程就是工作流程。

我一般会说学习新技术是有趣的、有趣的、有益的。你可以获得新的观点和理解。但在我看来，我正在做的项目过度使用了工作流程。它用于对象持久性、基于计时器的事件和进程状态跟踪。它可以做所有这些事情，但我不相信它会向系统添加任何内容。

根据我的工作流程 3 经验，我绝对是愤世嫉俗的，但到目前为止，我发现工作流程更难以调试，更难以集成，并且容易引入许多竞争条件场景，其中多个工作流程在不同的环境中独立活动我的流程的一部分。

如果您不需要使用工作流并且没有从使用它中获得任何具体的、切实的好处，那么为什么要给您的系统增加进一步的复杂性和风险呢？仅仅因为您“可以”或“可以”使用工作流程并不是充分的理由。如果您想深入研究，那么可以使用它构建一个玩具，或者可以将一两个工作流程以非关键角色放入您的系统中。

考虑您是否正在利用工作流程的任何特定且独特的功能。例如，能够测试并不是工作流程的一个特征；测试工作流程并不比测试代码块更容易。

在工作流程中可以做的事情很少是在纯代码中不能做的（我说“很少”是因为我确信有一些，但我不知道有什么）。您需要权衡您的收益和损失，并建立概念验证。