您可以将 WCF 数据服务（例如 OData、Astoria、ADO.NET 数据服务）与 NetTcpBinding 一起使用吗？
我正在考虑通过慢速卫星连接创建数据查询 WCF 服务，我真的很喜欢 WCF 数据服务。我看到的问题是 HTTP 是一种非常详细的格式，并且由于我所做的一切都是内部的和 .NET，是否可以使用 NetTcpBinding 来减少一些开销？
这可能吗？可取吗？
I'm looking at creating a data query WCF service over a slow satellite connection and I really like WCF Data Services. The problem I see is that HTTP is a very verbose format and since everything I'm doing is internal and .NET, is it possible to use NetTcpBinding instead to reduce some of the overhead?
Is this even possible? Advisable?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在我自己研究这个问题时，我遇到了关于自托管 WCF 的 MSDN 文章数据服务。本文指出，您可以使用 DataServiceHost< 托管该服务/a> 仍然需要 HTTP（它派生自 WebServiceHost）。
但您也可以使用 IDataServiceHost。以下是 MSDN 文章的摘录：
这篇文章似乎表明 MS 已将数据服务职责与网络接口职责正确分离。如果是这样，那么我应该能够编写一个 NetTcpDataServiceHost。有人写过 IDataServerHost 吗？有什么建议吗？
While researching this on my own, i ran across the MSDN article on Self-Hosted WCF Data Services. This article notes that you can host the service with DataServiceHost which still requires HTTP (it's derived from WebServiceHost).
But you can also roll your own host using IDataServiceHost. Here's an excerpt from the MSDN article:
The article seems to suggest that MS has properly segrated data-service responsibilities from network interface responsibilities. If that's so, then I should be able to write a NetTcpDataServiceHost. Has anyone ever written a IDataServerHost? Any suggestions?
不，WCF 数据服务构建在 REST 之上，而 REST 本身非常密切且完全基于 HTTP 动词，例如 GET、PUT、POST 等 - 您不能通过 NetTcp 运行这些动词，因为它们本质上与 HTTP 协议相关联堆。
也许您还有其他选择来减少传输的数据？调整您的对象 - 如果可以的话，修剪脂肪 - 一次检索的行数以及传输的属性/数据字段的数量。这可能是你最有希望的方法。
No, WCF Data Services are built on top of REST, and REST itself is very intimately and completely based on the HTTP verbs like GET, PUT, POST etc. - you cannot run those over NetTcp, since those are intrinsically tied to the HTTP protocol stack.
Maybe there are other options for you to reduce the data being transmitted? Tweak your objects - trim the fat, if you can - both on the number of rows retrieved at once, and the number of attributes/data fields transmitted. That's probably you're most promising approach.