和/或，何时使用其中之一？这是偏好问题还是存在技术差异？
关于我为什么要问的一些背景知识：我有一个运行 .NET 2.0 CF 应用程序的应用程序，并且用户正在执行几个快速操作。我不想阻止操作，但我希望 UI 显示等待图标或进度图标栏。
长时间运行的操作主要是由于 Web 服务调用，然后是设备本身对返回数据的一些处理。
编辑在查看吉姆的答案，特别是下面的引用之后，执行异步调用同时避免在 UI 线程上施加任何负载的最佳做法是什么？总是在单独的线程中调用 BeginGetResponse？
BeginGetResponse 方法需要在此方法变为异步之前完成一些同步设置任务（例如 DNS 解析、代理检测和 TCP 套接字连接）。因此，永远不应在用户界面 (UI) 线程上调用此方法，因为在引发错误异常之前完成初始同步设置任务可能需要相当长的时间（长达几分钟，具体取决于网络设置）或该方法成功。
在后台进行同步调用将在调用期间占用一个线程。
线程不是免费的。尤其是如果你打了很多电话，那可能会有很大的开销。
异步调用不涉及单独的线程，因此效率更高。
如果您进行异步 Web 服务调用，则 UI可能会在 DNS 解析期间被占用一小段时间。方法在进行异步方法调用以获取响应之前BeginGetResponse解析 DNS 。因此，如果 DNS 解析需要任何时间（通常非常快，但有时可能需要几秒钟），那么 UI 将在这段时间内无响应。
请参阅这真的是异步的吗？更多细节。
除此之外，只要您在回调中处理响应（在单独的线程上执行），UI 响应性就没有区别。此处的区别在于，对于异步请求，单独的线程仅在处理结果期间处于活动状态。使用线程执行同步请求时，线程在请求和处理的整个持续时间内都处于活动状态。对于大多数 Web 服务调用，处理所需的时间比发出请求并等待结果要少得多。
如果您发出大量请求，那么每次调用一个线程就会冒着资源耗尽的风险。但是在现代硬件上，你必须每秒发出几十个请求才能成为一个问题。
综上所述，您可能应该使用异步 Web 请求。如果您使用这些请求访问同一个域（或少数域），则 DNS 解析将从本地缓存中得到满足，这意味着它根本不需要任何时间。并且您减少（几乎完全消除）由于太多并发线程而导致资源耗尽的风险。
有趣的是，HttpWebRequest.BeginGetResponse的文档说：
BeginGetResponse 方法需要在此方法变为异步之前完成一些同步设置任务（例如 DNS 解析、代理检测和 TCP 套接字连接）。因此，永远不应在用户界面 (UI) 线程上调用此方法，因为在引发错误异常之前完成初始同步设置任务可能需要相当长的时间（长达几分钟，具体取决于网络设置）或该方法成功。
虽然这可能是一个很好的一般建议，但我上面的评论仍然适用：如果您的所有呼叫都转到同一服务器或同一组服务器（通常是内部应用程序的情况），那么该警告是无关紧要的。DNS 将被缓存，代理将被设置等。如果代理设置在每个连接的基础上花费大量时间，您需要与您的 IT 部门联系以获得解决方案。根据我的经验，异步 Web 请求是可行的方法。