我正在研究一些问题的不同方法：客户端请求工作，一些事情完成，并返回结果（ok / error）。
.NET Web服务肯定是要走的路，我唯一的问题是“内容”将涉及为每个请求构建和拆除会话。是否将“东西”抽象到应用程序（这将使单个会话保持活动状态，并处理来自Web服务的请求）似乎是正确的方法？ （如果是，那么通信方法）
工作时间可以忽略不计，我关心的是如果我为每个工作创建/删除会话，那么可能会得到有问题的交易服务器。
某种形式的IPC或基于套接字的通信在这里是一种可行的解决方案吗？
非常感谢思考/评论/经验。
编辑： 经过一番研究后，似乎在Windows服务中托管WCF服务可能是更好的方式......
答案 0 :(得分：1)
好吧，我们走了：
不要为每个请求设置新的通信通道。 CLient端/服务器端使用WCF实现并确保客户端没有为每次调用获得新的procxy;）特别是使用HTTPS通道设置是昂贵的。
不要打电话给服务;）这样简单 - 尽可能少打电话。将粗略的界面优化为不进行多次调用。允许批量处理结果。例如，“GetInvoice”可以是“GetDocuments” - 不仅返回发票，还需要多个ID，返回多个文档。 30个发票的列表从30个调用变为1.否则消息传递总线方法可能有效 - 我使用这样的方法，每次调用最多可传输1024个消息。
如果您有大量负载，请尽量不要使用Web服务。使用WCF和NetTcp绑定（二进制而不使用HTTP，因此它不是Web服务）。 HTTP开销是巨大的 - 查找谷歌，有人做了测试，我们谈论net tcp有时大约900 TIMES更快。特别是如果你做的很少，并且失去了用户，这可能会增加可扩展性。否定 - 您在客户端只兼容WCF，不再使用“Web服务”。
这几乎是你所能做的。有不同的损失，但这是如何获得性能;）如果你谈到纯粹的IPC考虑使用命名管道，甚至net.tcp - 命名管道都非常有效（使用进程之间的共享内存），但限于相同.NET实现中的机器。