Observables vs Tasks - 首选实现？答案

【问题标题】：Observables vs Tasks - preferred implementation?Observables vs Tasks - 首选实现？
【发布时间】：2012-02-09 18:05:28
【问题描述】：

我只是想异步检索数据，检索数据后，将其显示在 UI（Winforms）中。

使用 .net 4.0，有两种方法可以实现（我知道还有更多，但我正在使用这两种）：

    var task = Task.Factory.StartNew(() => RetrieveData());
    task.ContinueWith(x => SetDataInUi(x.Result), TaskScheduler.FromCurrentSynchronizationContext());

或

var obs = Observable.Start(() => RetrieveData());
obs.ObserveOn(SynchronizationContext.Current).Subscribe(x => SetDataInUi(x));

据我所知，它们都会做同样的事情。有理由选择其中一个吗？

【问题讨论】：

可能是错误的，但我认为您可以将 () => RetrieveData() 替换为 RetrieveData。同样将x => SetDataInUi(x) 替换为SetDataInUi。
@Domenic - 有可能，但我必须明确调用 StartNew

标签： .net multithreading c#-4.0 system.reactive

【解决方案1】：

如果你只是想从某个地方请求数据并将其打印到屏幕上，我更喜欢第一种解决方案。

第二个也可以，但 RX 旨在帮助您处理数据流。我们都同意，当您可以使用简单的解决方案时，使用复杂的解决方案并不酷:)

【讨论】：

Rx 版本更短，怎么更复杂？
他写的代码更短，但是 RX 使用的机制 if 用于比这更复杂的情况。这是一个用简单的事情来解决简单问题的问题。
有成长的空间也不错。如果他现在希望从用户交互中触发此获取怎么办？没有理由不从 Observables 开始，因为他最终想以更复杂的方式使用它。有时可维护性更重要，当然 Rx 更容易立即阅读和组合。我看到 Observables 可以用来做更复杂的事情，但这并不能让它们本身变得复杂。我发现这个选择比什么都更重要。
我不同意。 Rx 更具表现力（部分是由于使用了 LINQ 表达式）。 Rx 还能够将 .NET 中的所有异步和事件编程模型统一到一个模型中。值得为此使用。
如果它是一个简单的任务，我想在单独的线程上运行，我会使用一个任务。如果我觉得懒惰，我可能只使用后台工作者！如果我正在收集数据，我将使用 Rx 作为它在多个点进行过滤和订阅的简单方法。话虽如此，我的一些同事就是不明白。

【解决方案2】：

简短的回答是否定的，这两种实现之间不应该有很大的区别。

这些是不同的 API，它们提供不同的模型来描述相似的操作。

Task API 提供了一种避免直接使用线程的方法，而是处理您想要执行的单个任务。

Reactive API 提供了一种在不同操作之间高效汇集数据的方法。

在这种情况下，您的问题存在于两个领域。您正在处理一个不值得显式线程的小任务，并且您正在使用结果引导数据流。但是前一个定义是一个更完整的描述器，因此它可能是您应该使用的解决方案。

您现有的任何代码都使用这两种解决方案吗？匹配您在其他地方所做的工作有助于提高可读性，并忽略这一考虑。

另请注意，有时在比较 API 时必须考虑依赖关系，但在这种情况下并非如此，但一般情况下最好记住。

【讨论】：

这种情况下，我相信.Net Framework不会有问题。由于 Task API 是在 .Net 4 中引入的
@rodrigovedovato：我以为是 3.5，我会改写，我试图保持抽象但相关，但有点失败。