我们正在为我们的应用程序套件开发一个新的中间层。我们希望用C＃重写我们的业务逻辑和数据访问层，因为它们目前在VB6中并通过COM +发布。
我们要确定的是如何让这个中间层可供不同的客户使用。我们将使用WCF执行此操作，并且我们已决定使用各种绑定以满足每个不同客户端的需求，包括用于桌面应用程序的netTcpBinding，net.Tcp和/或命名管道绑定到本地或网络中的计算机上运行的互联网应用程序，以及外部Web API的某种HTTP绑定风格。
我们要确定的是如何托管我们的服务。似乎我去的大多数地方都说IIS是要走的路，但是如果它是在Windows服务下的话，看起来你会从BLL / DAL部分获得更好的性能，并且这里的@marc_s似乎经常推荐自我托管。那么我们是在IIS下，在服务下还是在某些混合下托管它，在IIS中为HTTP端点托管瘦服务并通过net.tcp或命名管道绑定来使用主服务？如果需要，将其分开可以实现物理隔离，并允许IIS关闭的可能性，这仍然会使访问其发布的端点的客户端运行服务。
此外，可扩展性和可靠性如何？这两种托管环境有什么区别吗？
我意识到有很多类似的问题，但是我找不到我一直在寻找的信息，所以链接到更具体的帮助就像答案一样。
答案 0 :(得分：3)
阅读这个答案似乎表明自托管是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