我们正在为我们的应用程序套件开发一个新的中间层。我们希望用 C# 重写我们的业务逻辑和数据访问层，因为它们目前使用 VB6 并通过 COM+ 发布。
我们试图决定的是如何使这个中间层对不同的客户端可用。我们将使用 WCF 来执行此操作，并且我们决定使用各种绑定(bind)来满足每个不同客户端的需求，包括用于桌面应用程序的 netTcpBinding、net.Tcp 和/或命名管道为在本地或在网络内的机器上运行的互联网应用程序绑定(bind)，以及为外部 Web API 进行某种 HTTP 绑定(bind)。
我们要决定的是如何托管我们的服务。似乎我去的大多数地方都说 IIS 是要走的路，但如果它在 Windows 服务下，你似乎会从它的 BLL/DAL 部分获得更好的性能，@marc_s 在这里似乎经常推荐自托管。那么，我们是将它托管在 IIS 下、服务下，还是某些混合托管服务(其中，瘦服务可能托管在 IIS 中用于 HTTP 端点并通过 net.tcp 或命名管道绑定(bind)使用主要服务)？将它分开允许在需要时进行物理分离，并允许 IIS 关闭的可能性，这仍然会使服务为访问它发布的端点的那些客户端运行。
此外，可扩展性和可靠性如何？这样两种托管环境之间有很大区别吗？
我知道有很多与此类似的问题，但我一直无法找到我一直在寻找的信息，因此指向更具体帮助的链接与答案一样有效。
最佳答案
阅读此答案似乎表明 marc_s 的偏好是基于接受自己编写主机代码的开销:
IIS WCF service hosting vs Windows Service
IIS 为您免费提供了很多东西。我想说事先考虑这一点并不是一个坏主意，但没有什么比测量性能指标更好的了，以获得关于什么最适合您的解决方案的冷酷事实。
尝试 IIS，如果它真的那么差，请创建您自己的主机。在 IIS 中运行它并不昂贵 - 网络上有一些调整技巧。
更新:在 marc_s 发表评论后发布了这篇文章。我原则上同意，但自己进行托管可能会被证明是无益的开销。 IIS 在某种程度上是开箱即用的，并且有其局限性 - 您可能永远不会遇到的局限性。
我不确定此反馈的相关性，但我们使用 IIS 为我们的应用程序托管 .NET Remoting 对象。它目前正在经历相当可观的性能指标收集过程，以准备因新客户而扩大近 10 倍。对于我们来说，IIS 还没有被确定为任何值得担心的事情。人们唯一的症结在于它是通过 HTTP(对我们来说是较旧的 IIS 版本)，因此与 TCP 相比，消息量更大一些。
更新:这篇 MSDN 文章涉及自托管并讨论了一些需要考虑的要点:
http://msdn.microsoft.com/en-us/library/bb332338.aspx#msdnwcfhc_topic3
关于c# - 中间层的 WCF 托管，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5318339/