我在 azure 中部署了 WCF 服务。我有一个使用此服务的客户端，该服务在 Windows Phone 7 上运行。一切正常，但是当我尝试向服务器发送一些较大的文件或丢失项目的枚举时，发生了错误。我发现可以在配置文件中配置最大消息大小、最大数组长度等。所以我在默认值中添加了几个零并且它起作用了。但是，我对这个解决方案不满意，因为它很脏。
我的问题是：
1.盲目地增加消息大小限制的缺点是什么，它如何影响服务？
2.我有什么替代方案而不是增加消息大小？
特别是，我需要向服务器发送包含相同元数据和大量位置点的 GPS 轨迹。
如果我正确理解概念，默认情况下 wcf 使用基于 XML 的 SOAP。所以发送的对象被编码为 XML（类似于 .net 中的 XML 序列化？）。那么它可以以某种方式切换到某种二进制模式来发送 BLOBS 或上传大型对象流吗？还是我唯一的选择是完全绕过 WCF 服务并直接上传到服务器存储（如 SQL azure 或 Azure Blob 服务），这会公开 API 来这样做？
谢谢你。
正如佩雷茨在评论中提到的那样，这就是应该发生的事情。
默认值就是-- defaults。不是“推荐”设置，也不是伪最大尺寸。它们可以根据您的需要进行更改（并且应该是）。
您可以使用 net.tcp 绑定（如果您还没有），它可以更好地处理数据（关于序列化），但您所做的一切都在 WCF 及其能力的范围内。
我对巨大的 gps 轨道有同样的问题。我真的建议不要将肥皂用于此类任务。您可以使用 WebHttpBinding 并从您的存储中实现流式传输，或者使用 ASP.NET WebAPI（将随 MVC4 提供并且可以在 IIS 之外托管）之类的东西来将流传输到客户端的低级别管道。这将允许您实现多个下载流以及此类任务中可能需要的所有内容。
在此类系统的整体设计理念中，尽量不要认为一种工具可以解决您的问题。只需使用正确的任务。如果您有一些业务任务 - 为他们实现基于事务的 ws-* 服务。要传输大量数据 - 使用 REST 服务之类的东西。这也将有助于查询曲目。
例如：Tracks/{deviceid}/{trackDate}.{format}。
随意问=）
您不应通过在这些设置的末尾添加 0 来任意增加消息大小。是的，它们是可以更改的默认值，但是在达到限制时增加消息大小并不是您应该始终采用的方法。具有如此小尺寸的原因之一是安全性：它可以防止客户端用大量消息淹没服务器并将它们关闭。它还鼓励客户发送有助于可扩展性的小消息。
您可以使用一些编码：这取决于使用的绑定。我认为 WCF 无论如何都会将 SOAP 编码为二进制......但我可能错了，我已经有 6 个月没有接触过 WCF 了。
在以前的项目中，每当我们达到大小限制时，我们都会考虑将数据切割成更小的块。我们做过的最好的事情之一是在我们的 GUI 中实现可分页网格，它一次只能从服务器获取 10-20 条左右的记录。Entity Framework 允许我们编写一个通用的跳过获取查询来为我们所有的网格执行此操作。
只是增加尺寸是一个简单的解决方法......直到你不能进一步增加。这是一种脆弱而破碎的方法。