WP7-对网络通信、跨线程访问和连续传递感到困惑

Question

我正在将 WPF 应用程序移植到 WP7，在此过程中我必须重构所有涉及网络的代码。旧代码在后台线程中使用WebRequest对象的同步方法，但这些方法在WP7中不再存在。

结果令人困惑，让我觉得我做错了什么。我不得不用线程调度代码来乱扔我的视图 - 我看到的唯一替代方案是将调度程序提供给应用程序的较低层，这会破坏平台独立性并混淆与 UI 的边界。我已经失去了从循环中通过网络进行链式调用的能力，而是让回调调用自身。我失去了 try/catch 错误处理，而是到处都有 OnSuccess 和 OnError 回调。我现在总是无意中在回调调用的后台线程中运行代码。我深深地记得那些能够从方法返回值的日子。

我知道连续传递风格应该很棒，但我认为上述所有内容都使代码变得更加脆弱且可读性较差，并且使线程问题变得比需要的更加复杂。

如果这个问题含糊不清，我很抱歉，我只是想知道我是否在这里错过了一些大局。

Answer 1

这是Silverlight的限制，它需要异步网络访问（WCF代理调用、WebClient、WebRequest等）。所有同步网络依赖方法调用已从框架中删除。

说得粗俗点：欢迎来到异步编程。你做错的唯一一件事就是没有首先使调用异步:)

我不是 100% 清楚 MS 从 Silverlight 中的 Web 相关对象中删除同步调用的确切原因，但我听到的解释总是集中在一两个原因的组合：

• 浏览器是基于异步网络调用构建的。引入同步调用会导致不良行为/应用程序损坏/崩溃等。
• 如果他们让每个人都能“轻松地”进行同步调用，那么世界上就会充斥着在网络上执行任何操作时总是冻结的 Silverlight 应用程序，这使得 Silverlight 作为一个平台看起来很糟糕。

也就是说，Silverlight 中的 WCF 代理具有始终在调用线程上执行回调的行为。这通常是 UI 线程，这意味着您不必执行任何调度。我不知道 Silverlight 中的 WebClient/WebRequest 是否也有这种行为。

至于调度程序，您可以考虑使用 SynchronizationContext。 MS 模式和实践 Prism 指南中的 MVVM 参考实现就是这样做的 - 在存储库（实际上调用抽象外部服务的数据访问类）中，它们有一个 SynchronizationContext 成员，该成员被初始化为 System.Threading.SynchronizationContext.Current 。如果在 UI 线程上调用构造函数（应该是），则这是 UI 线程。然后，服务调用的所有结果都将使用 mySynchronizationContext.Post 进行处理。

Answer 2

像这样的问题似乎表现得像公共汽车。你很长时间都没有看到任何一个，然后两个几乎同时出现。请参阅今天早些时候提出的这个问题的更具体版本的答案。

我必须同意你的观点，连续传递是很棘手的。一项真正有用的技术是借用 C# yield return 构造来创建能够在异步操作之间维护状态的机器。有关真正好的解释，请参阅 Jeremy 的博客相似度。

就我个人而言，我更喜欢“少即是多”的方法，因此 AsyncOperationService 是一小块代码。您会注意到，它对于成功和失败都有一个回调，并且没有接口可以仅实现中等委托 Action>（类型为 AsyncOperation） code> 使其更方便。

针对此问题进行编码的基本步骤是： -

• 编写代码，就好像同步执行是可能的一样
• 创建返回 AsyncOperation 的方法，仅保留必须异步的最小部分。通常会进行一些 WebRequest 或 WCF 调用，但请注意足以通过异步位，请参阅我的其他答案以获得一个很好的示例。
• 将同步“伪代码”转换为 yeild 这些 AsyncOperations 并将调用代码更改为“运行”结果可枚举。

最终代码看起来与您可能更熟悉的同步代码非常相似。

至于在后台线程上意外运行的内容，最后一个答案包括这个有用的 AsyncOperation： -

public static AsyncOperation SwitchToUIThread()
{
    return (completed => Deployment.Current.Dispatcher.BeginInvoke(() => completed(null)));
}

您可以将其用作运行中的最终yield，以确保代码在completed中执行code> 回调正在 UI 线程上执行。必要时“翻转”在 UI 线程上运行的明显同步代码也很有用。