直到最近,关于在 .NET、Silverlight、Windows Phone 和 Windows Store 之间分享代码的问题之一,依旧是缺少发起 HTTP 请求的能力。每个框架支持一个或多个 HTTP 客户端,但在 API 层面它们互不兼容。
要解决该问题,开发者可以创建自己的平台相关适配器,并使用依赖注入把它们添加到有需要的可移植库中。而基本上,这也正是新的可移植 HttpClient 所做的事情。
当然,每个版本的 HttpClientHandler 都有不同的功能集。所以,为了尽可能地将更多的功能暴露出来,可移植 HTTP 客户端引入了诸如 SupportsUseProxy 和 SupportsAllowAutoRedirect 这样的扩展方法。
Immo Landwerth 解释道:
倘若开发者想要知道为何我们添加扩展方法而不是常规属性的话:某些 Microsoft.Net.Http 支持的平台已经提供并正在使用 HttpClientHandler 类。由于不能直接修改属性的内建版本,我们添加了扩展方法并通过 NuGet 包以独立程序集的方式发布。
基于以下原因,微软正在变得越来越青睐类似于可移植 HttpClient 这样的小型、带外发布:
首先,它搭建了一座桥梁以跨越我们已经发布的平台之间的差异。HttpClient 是一个很好的例子,同样的还有对 async 和 await 关键字的支持。带外发布特性允许我们通过单一可移植类库针对多平台发布新功能,而无需等待其中任何一个平台添加该功能。
其次,我们的目标是增强与客户之间的反馈回路。过去,我们发布“大型”beta 版本,例如整个 .NET 框架的 beta 版本。这一方法当然有其优势,但我们也发现了它的问题。其中最大的缺点是“大型”beta 版发布代价高昂,而且它一般与 RTM 非常接近,这也就意味着我们不能再进行重大变更。实际上,我们必须拒绝大量在“大型”beta 版本中获得的 bug 报告,因为它们仅影响了相对小众的客户,或是因为修订这些 bug 会把 RTM 版本置于风险之中。我们当然不是第一家遇到这个问题的公司;在这个产业里,整个敏捷软件开发运动都在聚焦于此。虽然我不想开启关于敏捷方法论的哲学讨论,但是很难否认尽早并经常发布对反馈回路的问题是有帮助的。
某些开发者期望的特性未能纳入这次候选发布,其中最重要的是对自动解压缩的支持。为了不推迟本次发布,该特性将在完成后出现在后续版本中。
为了在诸如 Silverlight 等老平台上支持 async/await,可移植 HttpClient 依赖 BCL 可移植性包。