我正在开发一个基本上是n层协作应用程序的新架构（不是企业级，只是一个有可能大幅增长的小项目），我已经在努力训练自己使用IoC，以及在某种程度上，TDD，我想知道，一般来说，只是手工编写工作流逻辑是否明智，或者我是否应该深入学习和集成WF4（Windows Workflow 4.0，.NET 4.0的一部分）以便WF从字面上看，它就是整个应用程序的控制器，即“MVC”中的实用C（不是ASP.NET MVC，而是模式）。那么 WF4中的工作流活动应该是高度可扩展/可扩展的基于Web的协作应用程序的主要控制器吗？或者我完全问错了问题？
这是一个模糊的问题，我敢肯定，因此抽象的答案与特定答案一样受欢迎。
我知道WF4是对WF3进行重大改造和重新设计的地方，其中很多使WF3成为糟糕技术选择的因素已经在WF4中得到了清理。例如，据我所知（尽管我看起来并不是很努力，并且几乎没有对此进行报道），WF4活动或多或少可以通过[TestMethod]和模拟来测试（可以有人在知道请确认？WF的可测试性对我们来说是一个巨大的问题）。我对使用WF的XML图表或后期加载很感兴趣，我更喜欢编写具体的C＃工作流声明，但如果工作流可以用编译语言简洁地编写并且可以测试，我很想付钱注意它。因此，如果有这些改进，其他诸如改善性能之类的技术再次引起了我对该技术的关注，而我之前对WF3进行了嘲讽。
此外，根据微软的说法，WF4是微软希望在未来使用MS CRM，MS SharePoint等不同工作流技术的经验教训后，为所有工作流程驱动的产品标准化的。我当然很好奇关于投注一个通用的功能，但只有实现可以简洁，在编译时进行类型检查，可测试和可维护。
编辑：只有那些了解WF4（不是WF3）的人才会回答“答案”。
答案 0 :(得分：2)
不，我不会把它放在一切的中间。
我目前正在参与一个广泛使用工作流程3的项目。这不是工作流程4，我知道WF4有很多改进，但......工作流程是工作流程。
我一般会说学习新技术既有趣又有趣。您可以获得新的观点和理解。但在我看来，我工作的项目是过度使用工作流程。它用于对象持久性，基于计时器的事件和进程状态跟踪。它可以做所有这些事情，但我不相信它会给系统增加任何东西。
基于我的工作流程3经验，我绝对是愤世嫉俗，但到目前为止，我发现工作流程更难以调试，更难以集成，并且可能引入许多竞争条件场景，其中多个工作流程是独立的在我的过程的不同部分活跃。
如果您不需要使用工作流程并未获得使用它的任何具体，实际的好处，那么为什么会为您的系统增加更多的复杂性和风险？仅仅因为你“可以”或“可以”使用工作流程并不是充分的理由。如果您想将其深入研究，然后使用它构建一个玩具，或者将一个或两个工作流投入到非关键角色的系统中。
考虑您是否正在使用工作流程的任何特定和独特功能。例如。能够测试不是工作流程的一个特征;测试工作流程并不比代码块更容易。
在工作流程中你很少能用普通代码做的事情（我说'很少'因为我确定有一些，但我不知道）。你需要权衡你的收益和损失，并建立一个概念证明。