我们公司一直在争论我们是否应该使用自定义API DLL或创建Web服务场来让我们的程序在它们之间进行数据通信。对我来说，Web服务在升级的兼容性和灵活性方面最有意义，但我也听说过使用DLL的一些很好的理由。
是否有新兴的.NET应用程序，或者您发现哪种选择效果最好？如果是这样，为什么？
谢谢！
答案 0 :(得分：9)
我想我会说WCF。原因很多：
在过去，远程处理是炸弹，因为Web服务无法真正做到安全等等，而不必知道WS- *，这是令人生畏的。现在不适用于WCF。是的，它附带了一个学习曲线，但你正在学习可以转移到任何其他微软商店的东西。
请确保您阅读了正确的WCF方式。例如，将所有消息传递内容分成它自己的单独DLL。
答案 1 :(得分：5)
DLL或程序集本身不能解决程序之间的通信问题。但是，在过去构建程序集时，我所做的是利用共享内存空间，自定义DLL用于跨应用程序访问共享对象。我已经为具有附加Outlook加载项的应用程序完成了这项工作，并且非常成功。
这种方法的优点是它比使用Web服务路径更快。
但是，我认为这实际上归结为你的情况，因为我可以看到在不同情况下使用多个场地。
共享内存/ Web服务/远程处理/ WCF，仅举几例。
答案 2 :(得分：4)
我们使用各种各样的东西，主要取决于它们的部署地点，谁是“客户”以及谁是“威胁”。我们主要使用webservices来处理桌面应用程序所触摸的内容，但对于需要相互通信的基于服务器的应用程序的部分，我们使用远程处理（因为它不会通过负载平衡器路由，而Web服务将是每个人都可以看到）。
答案 3 :(得分：4)
有优点＆amp;各自的缺点 - 如果你总是运行.net应用程序，那么你可以说从dll方法获得更好的性能。远程处理也可以很好地工作。
为了获得更长期的灵活性，您可以轻松地与其他平台集成。如果需要，您可以考虑为应用程序构建RESTful Web服务API。
在某些情况下，我曾经通过一些精心设计的存储过程在数据层中进行应用内部通信的地方工作，这些存储过程在该场景中完美运行。
我总是考虑最适合手头任务的工具，而不是试图适应任何特定的趋势，但是，如果你做任何可能涉及外部客户互动的事情，我肯定会看看是否有公布的通信标准已经到位，您可以选择 - 您可以使用许多标准来帮助您的行业内的互操作性。
答案 4 :(得分：3)
所有.net / MS商店通常会处理与Web服务的通信，因为microsoft使这一点相对容易。
我在实践中发现的唯一问题是，由于传递消息的大小限制，我们曾经遇到过生产故障。它默认为兆字节，并且非常大的序列化对象无法适应该空间。它使用序列化来代替文本而不是二进制文件。
在我们的设置中，它是SOA架构的全部内部，我们不必担心威胁。
答案 5 :(得分：3)
正如大多数其他海报所指出的那样，如果没有更具体的细节，很难提供建议。
如果您的要求允许异步消息传递，您可能需要考虑将System.Messaging与Message Queue结合使用作为第三种选择。
答案 6 :(得分：2)
对于我们的应用，我们选择了混合物。我们使用Web服务通过Internet来实现负载平衡和第三方开发，但使用tcpchannel远程处理以允许服务器之间的快速通信。这取决于问题。
答案 7 :(得分：2)
如果进程是一台独立的计算机，则您的选择主要是Web服务/ WCF，.NET远程处理或直接TCP / IP连接。如果进程在同一台机器上，那么您可以选择更多选项，包括共享内存和文件系统。如果你不需要与任何其他技术互操作，.NET远程处理应该近距离观察 - 它不需要codegen来完成它的工作，所以更简单，具有良好的性能。
答案 8 :(得分：2)
WCF真的是这里的方式 - 编写服务，让配置决定传输介质。
在选择传输介质方面，很多都与您的网络架构和要求有关。 Http非常适合远程访问和通过防火墙但是效率低下而Tcp可以快速但不可靠。