在什么情况下在同一台计算机上运行 WCF 客户端和服务器才有意义？
在 Michele Bustamante 的学习 WCF 中，有一个部分描述了名为 NetNamedPipes 绑定的绑定。书中说，这种绑定只能用于从同一台机器专门调用的 WCF 服务。
在什么情况下使用它才有意义？通常，我会在不使用WCF的情况下编写异步代码...为什么微软会为WCF提供只能在同一台机器上运行的东西？
In Learning WCF, by Michele Bustamante, there is a section that describes a binding called the NetNamedPipes binding. The book says that this binding can only be used for WCF services that will be called exclusively from the same machine.
Under what circumstances would it make sense to use this? Ordinarily, I would write asynchronous code without using WCF... Why would Microsoft provide something for WCF that can only run on the same machine?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从另一个方向看。服务构建完成后，您可以在各种绑定配置中运行。如果它是远程计算机，您可以使用 HTTP 或 TCP 绑定。或者，该服务恰好在同一个机器上运行，您可以使用这些选项加上命名管道选项。命名管道只是在本地运行时提供的另一个选项，但如果您在远程运行，则应该能够切换到不同的绑定。
Yu 可以从同一个盒子上的所有内容开始，因为流量较少，并使用命名管道，因为这是到达服务的最短路径。然后，如果负载需要，您可以将服务移动到另一个盒子，然后将其更改为使用 TCP 或 HTTP。
Look at it from the other direction. Once the service is built, you can run in in a variety of binding configurations. If it was a remote machine, you could use the HTTP or TCP bindings. Or, the service happened to be running on the same box, you have those options plus the named pipes option. The named pipes is just another option that is provided just in case you are running locally, but you should be able to switch to a different binding if you are running remote.
Yu could start with everything on the same box because you have less traffic, and use named pipes because it was the shortest path to the service. Then, if load demanded it, you can move the service to another box, and then change it to use TCP or HTTP instead.
您可能不会拥有仅公开 NetNamedPipe 端点的服务 - 这没有多大意义。但是，如果您在服务器上运行 WCF 服务，使用通常的绑定向世界公开服务端点，并且您需要在同一台计算机上运行的管理或管理控制台或类似的东西，那么使用NetNamedPipe 绑定，因为它是最快的。
我了解到的另一种可能的情况是拥有错误收集服务 - 发生的任何错误或异常都会发送到要记录的服务。再次强调：该服务可能会公开多种类型的端点，但如果您在同一服务器上运行其他服务，则使用 NetNamedPipe 绑定来连接这两个服务非常有意义。
我认为您在 WCF 时代不会经常使用 NetNamedPipe 绑定 - 但它在某些情况下绝对有意义，并且在此类特殊场景中非常有用。
You probably won't have a service that exposes only a NetNamedPipe endpoint - that doesn't make a lot of sense. But if you run your WCF service on a server, exposing service endpoints out to the world using the usual bindings, and you need e.g. a management or admin console or something like that, running on that same machine, it can make sense to use the NetNamedPipe binding since it's the fastest around.
Another possible scenario that I learned about is having an error collection service - any error or exception that happens is sent to a service to be logged. Again: that service would probably expose several types of endpoints, but if you have other services running on the same server, using NetNamedPipe binding to connect these two services makes a lot of sense.
I don't think you'll use the NetNamedPipe binding an awful lot in your WCF days - but it can definitely make sense in some cases and be quite useful in such specialized scenarios.