.NET WF4：它应该位于一切的中间吗？
我正在开发一个新的架构，本质上是一个 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 很不屑。
此外，根据 Microsoft 的说法，在从 MS CRM、MS SharePoint 等中使用不同的工作流技术吸取经验教训后，WF4 是 Microsoft 希望在未来所有许多工作流驱动的产品中实现标准化的标准。我当然对押注于 WF4 感到好奇这是一种万能的功能，但前提是实现能够简洁、在编译时进行类型检查、可测试和可维护。
编辑： 只有了解 WF4（而不是 WF3）的人的答案才会被视为“答案”。
I'm working on a new architecture for essentially an n-tier collaborative application (not enterprise-class, just a smallish project with potential to grow significantly) where I'm already trying to discipline myself to use IoC and, to some extent, TDD, and I'm wondering, in general terms, whether it is wiser to just hand-code workflow logic or if I should delve into learning and integrating WF4 (Windows Workflow 4.0, part of .NET 4.0) so that WF becomes literally the controller of the entire application, i.e. the practical C in "MVC" (not ASP.NET MVC but rather the pattern). So should workflow activities in WF4 be the primary controller for a highly expandable/growable web-based collaborative application? Or am I asking entirely the wrong question?
This is a vague question, I'm sure, so abstract answers are as welcome as specific ones.
I am aware that WF4 is a significant rework and redesign of WF3, where much of what made WF3 a poor technology choice has been cleaned up in WF4. For example, as far as I can tell (although I haven't looked very hard, and there's been virtually no coverage on this), WF4 activities are more or less testable with [TestMethod] and mocking (can someone in the know please confirm? .. testability of WF is a huge concern for us). I have very little interest in the diagramming or late-loading via XML with WF, I much prefer to write concrete C# workflow declarations, but if a workflow can be written succinctly in a compiled language and can be testable, I'm tempted to pay attention to it. So if these improvements are there, these among others like improved performance have grabbed my attention about the technology again, whereas I had previously pooh-poohed WF3.
Also, according to Microsoft, WF4 is what Microsoft wants to standardize upon for all the many workflow-driven products in the future, after lessons learned from having different workflow technologies in MS CRM, MS SharePoint, etc. I am certainly curious about betting on a one-size-fits-all feature, but only if implementations can be succinct, type-checked at compile-time, testable, and maintainable.
EDIT: Only answers from those who know WF4 (not WF3) will be considered for "the answer".
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不，我不会把它放在所有事情的中间。
我目前正在参与一个广泛使用工作流程 3 的项目。它不是工作流程 4，我知道 WF4 有很多改进，但是...工作流程就是工作流程。
我一般会说学习新技术是有趣的、有趣的、有益的。你可以获得新的观点和理解。但在我看来，我正在做的项目过度使用了工作流程。它用于对象持久性、基于计时器的事件和进程状态跟踪。它可以做所有这些事情，但我不相信它会向系统添加任何内容。
根据我的工作流程 3 经验，我绝对是愤世嫉俗的，但到目前为止，我发现工作流程更难以调试，更难以集成，并且容易引入许多竞争条件场景，其中多个工作流程在不同的环境中独立活动我的流程的一部分。
如果您不需要使用工作流并且没有从使用它中获得任何具体的、切实的好处，那么为什么要给您的系统增加进一步的复杂性和风险呢？仅仅因为您“可以”或“可以”使用工作流程并不是充分的理由。如果您想深入研究，那么可以使用它构建一个玩具，或者可以将一两个工作流程以非关键角色放入您的系统中。
考虑您是否正在利用工作流程的任何特定且独特的功能。例如，能够测试并不是工作流程的一个特征；测试工作流程并不比测试代码块更容易。
在工作流程中可以做的事情很少是在纯代码中不能做的（我说“很少”是因为我确信有一些，但我不知道有什么）。您需要权衡您的收益和损失，并建立概念验证。
No, I would not put it in middle of everything.
I'm currently involved with a project making extensive use of workflow 3. It's not workflow 4, and I understand there are a lot of improvements in WF4, but... workflow is workflow.
I would generally say that it's fun, interesting and beneficial to learn new technologies. You can gain new perspectives and understandings. But in my opinion the project I am working is overusing workflow. It's being used for object persistance, timer-based events and process status tracking. It can do all of these things, but I don't believe that it's adding anything to the system.
I'm definitely cynical based on my workflow 3 experience, but so far I have found workflow to be more difficult to debug, more difficult to integrate, and liable to introduce a lot of race-condition scenarios where multiple workflows are independently active in different parts of my process.
If you don't need to use workflow are not gaining any specific, tangible benefit from using it, then why add further complexity and risk to your system? Just because you 'can' or 'could' use workflow is not sufficient reason. If you want to delve it into then built a toy using it, or maybe throw one or two workflows into your system in non-critical roles.
Consider whether you are utilizing any of the specific and unique features of workflow. E.g. being able to test is not a feature of workflow; it's not going to be easier to test a workflow than a block of code.
There are very few things that you can do in workflow that you can't do in plain code (I say 'very few' because I'm sure there are some, but I don't know of any). You need to weigh up your gains and losses, and built a proof of concept.