C# 两个独立应用程序之间的通信

我开发了一个从数据库读取数据的windows服务，该数据库通过ASP.net MVC应用程序填充

我需要通过向数据库发出select查询，使服务重新加载内存中的数据。此重新加载将由web应用程序触发。我已经想到了一些方法来实现这一点，例如远程处理、MSMQ，或者简单地让服务在套接字上侦听reload命令

---

我只是在寻找关于如何实现这一点的最佳方法的建议。

我会使用标准TCP套接字-这将经受住各种组件移动，并将配置问题降至最低。

只需在Windows服务中托管WCF服务即可。您可以使用

netTcpBinding

进行绑定，该绑定将使用TCP/IP上的二进制文件。这将比套接字简单得多，但更易于开发和维护。

通知的可靠性如何？如果一个通知丢失了（比如说，通信管道在路由器中出现了一个小故障，并掉下了插座），世界末日会到来还是一切照旧？如果服务关闭，是否需要在服务启动时排队等待来自网站的通知，或者可以安全地删除这些通知

您需要的可靠性越高，就越需要使用排队解决方案（MSMQ）。如果可靠性不是问题，那么您可以从非排队解决方案（远程处理、TCP、UDP广播、HTTP调用等）中进行选择

你在乎安全吗？您是否害怕攻击者将您的“刷新”击死，导致至少一个DoS（如果不是更糟的话）？是否要验证进行“刷新”调用的网站？您是否需要通知的隐私（即加密）？UDP更难保护（无会话）

该解决方案是否必须允许在现场轻松部署、配置和管理（即，是一个独立、打包的产品），或者是一个一次性部署，可以在发生变化时“及时”修复

如果我们不知道所有这些因素的细节，就很难说“使用X”。至少有一件事是肯定的：远程处理现在已经有点过时了

我的建议是使用WCF，因为它可以轻松地动态更改绑定，因此您可以在不更改任何代码的情况下测试各种配置（TCP、NetPipe、http）

---

顺便说一句，您是否考虑过使用来检测数据更改，而不是使用网站上的活动通知？我认为这是一次冒险，但在许多数据库上都存在同等的主动缓存支持。

这是我没有考虑过的一个选项，谢谢你的建议，我将对此进行研究。这里有很多很棒的信息，非常感谢。这不是业务关键，所以我不关心通知排队。我将调查WCF路线，尽管我的经验非常有限。查询通知看起来也很有趣。给WCF一个机会，是值得的。如果没有WCF，则TCP甚至UDP广播。远程处理和MSMQ似乎有些过分。