EF/WCF：减少数据传输

Question

希望这不是太开放。我正在开发一个.NET 4, WPF, WCF, EF (STE's), SQL 2012 应用程序。

我们受到客户的抨击，因为我们的应用程序在没有太多可用带宽的情况下超时并挂在较慢的网络上。

我们的应用程序有一些类似仪表板的“实时”显示以及一些基于网格的数据编辑器屏幕。

使用 Fiddler，我仔细研究了产品中的不同功能区域 - 特别关注正在传输的数据量。简而言之，传输的数据太多了 - 我们的一些 WCF 调用在一次调用中检索了超过 100 MB 的数据。

我相信我们所看到的问题的特征在于，在通过 WCF 和 EF 检索数据时根本没有采取足够的谨慎措施，但也许我分析得太多了：

• 我非常喜欢可重复使用性，但为什么要退回完全水合的 当您只需要一个 id 和一个选项列表的名称时，EF STE 实体？ 有时，我们只需要对数据进行简单的只读显示。为什么 序列化 ChangeTracker 信息，包括 OriginalValues 收藏等？也许，值得将实体拆分为 可编辑和“只读版本”或选择合适的版本？

• 现在，我们正在使用 BasicHttpBinding/XML 序列化，但是 有效载荷似乎臃肿。例如，xml 包含命名空间和 一堆其他的噪音。启用 IIS 7 压缩有帮助 剧烈，但我们还能做更多吗？ JSON格式会是一个 传输数据的更好选择？将 XML 更改为 JSON 似乎是这样 不过发生了重大变化。

• 是否有任何其他技术可用于缓解 有效负载大小——也许我们可以坚持使用 XML 序列化，但我们 只需要请求更少的数据。也许使用分页等技术 或“无限滚动”、延迟背景加载等。 不错的选择。

是否有其他人面临过大到无法接受的有效载荷大小？你做了什么来解决它？

谢谢！

Answer 1

我认为你已经涵盖了大问题。

尽可能使用 DTO 而不是完整实体（仅包含您需要的数据的简单数据类型）。您只需要一个简单的翻译类 - 您甚至可以使用代码生成工具或 AutoMapper 之类的工具来帮助您。

使用 NetTcpBinding 而不是 BasicHttpBinding - 这将显着减小消息大小，但您将失去 HTTP/Fiddler 调试，并且需要一些 IIS 配置。

或者，如果您想坚持使用 HTTP 并使用 JSON 而不是 XML，那么您将无法使用 WCF BasicHttpBinding 轻松做到这一点，因为那是 SOAP，但您可以换档尝试 WebAPI。不过，这对客户端和服务器来说都是一个重大变化。

那些应该会减少你的尺寸。从那里开始，继续探索以块的形式引入数据，或者使用大量单独的查询而不是一个大查询。即使这些不会降低整体带宽，它们也会提供更好的用户体验。