【问题标题】:Should I use TPL Dataflow to fight against complexity if there is no concurrency?如果没有并发,我应该使用 TPL Dataflow 来对抗复杂性吗?
【发布时间】:2016-06-21 19:33:57
【问题描述】:

我有一个项目在语义上具有工作流块。该解决方案不涉及任何并发或 CPU 绑定操作,也不需要可扩展性。我只有一个输入,它被处理并通过块的管道传递。每个块处理该项目并做出决定并将其传递给下一个块。为了对抗复杂性,可以使用 TPL Dataflow,还是因为没有并发性而过度杀伤,我应该使用常规的 OOP 策略?换句话说,TPL DataFlow 是适合这项工作的工具吗?

【问题讨论】:

  • 关于这个==> "解决方案不涉及任何并发",你的意思是并发是不需要的还是不需要的?因为当您将多个 TPL 数据流块链接在一起时,您具有自然的并发性,因为第一个块的输出由第二个块处理,而第一个块同时处理一个新的输入值。为了避免管道中的并发,您必须采取特定措施,例如使用相同的ConcurrentExclusiveSchedulerPair.ExclusiveScheduler 配置每个块。
  • 多年后回首往事,我已经切换到函数式编程范式并使用 Haskell Arrows(尽管在 F# 中)来完成这项任务。当涉及并发时,我使用的是 akka.net 流。
  • 嗨 Onur。我没怎么玩过 Akka.Net,所以我不知道它与 TPL Dataflow 相比如何。如果您有实践经验和意见可以分享,我很乐意阅读! Here 是一个相关问题,如果您愿意,可以在其中分享您的意见。

标签: c# tpl-dataflow


【解决方案1】:

DataFlow 正是针对您不需要的因素 ("The solution does not involve any concurrency or CPU bound operations nor scalability is required")。

方法链有什么问题?

var input = ...;
var result1 = F1(input);
var result2 = F2(result1);
var result3 = F3(result2);
return result3;

您所描述的内容非常简单,我认为无需再做任何事情。特别是不清楚(但可能)OOP 是否匹配。您尚未描述对象或数据。您已经描述了一个映射到代码而不是对象的过程。

【讨论】:

  • 你是对的。有时我有过度设计事物的习惯。需要第二意见。谢谢。
  • 应该是F2(result1)F3(result2)
猜你喜欢
  • 1970-01-01
  • 2021-07-10
  • 1970-01-01
  • 1970-01-01
  • 2012-08-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-02-17
相关资源
最近更新 更多