CF现在还是有很多人用的，不知道你现在在使用吗？如果你不用的话你就是落伍的人了，我们就WCF承载环境问题分析一下吧。Microsoft 在确保服务开发人员无需过分考虑WCF承载环境方面所做的努力是值得肯定的。ServiceHost 排除了所有技术性的难点，使您可以重点关注服务逻辑，而不必过多地考虑如何承载服务。您必须根据自己的具体要求选择一个宿主。WCF 主要是作为编程模型而编写的，其主要设计目的之一是为了实现“宿主的不可知”。ServiceHost 不关心自身在哪里被实例化，只要您希望服务可被访问时它正在运行即可。也就是说，它需要一个运行 .NET 应用程序域的进程。
#T#在选择应用程序类型时，必须考虑某些特定要求（例如，程序属于控制台应用程序还是 WinForms 应用程序等）。ServiceHost 必须被实例化才能提供运行服务所需的WCF承载环境。典型的 .NET 应用程序（例如，控制台应用程序和 WinForms 应用程序）通常运行在用户桌面计算机上。这些环境并非始终运行，它们可以承载您的服务，但却并非典型的适用于企业的宿主。我们认为适用于企业的宿主应该能够支持更大规模的面向服务的体系结构，在这种体系结构中，多个系统需要依赖服务所公开的关键业务功能。这些适用于企业的宿主通常能够满足诸如高可用性的要求。因此，我们不能将控制台或 WinForms 应用程序做为适用于企业的宿主。
通常情况下，服务运行在服务器上，并由操作员进行管理和操作。管理服务器的操作员一般不希望在服务器重新启动时手动启动控制台应用程序或 WinForms 应用程序。为了让服务应用程序能够在数据中心运行，对于企业级面向服务的情况来说，***可行的方案就是在 IIS 上承载服务，或将其作为一项 Windows 服务。
有时，您需要在用户的桌面计算机上实现进程间通信。在这种情况下，只有当用户使用应用程序时，服务才是活动的。需要进行进程间通信的典型应用程序就是控制台应用程序和 WinForms 应用程序。这些应用程序适合承载这些类型的服务。
要能够确定哪种宿主最适合您的情况，您应当考虑到非功能性要求。一般来讲，非功能性要求规定了应用程序的技术要求，以确保其达到应用程序要求的质量和可维护性。对于 WCF 应用程序来说，非功能性要求实际涉及以下内容：
◆可用性：希望何时能够访问您的服务？
◆可靠性：当服务由于某些原因出现中断时会发生什么问题？这将如何影响服务的其他使用者？
◆可管理性：是否需要便捷地了解承载 WCF 服务的宿主上所发生的情况？
◆版本控制：是否需要提供对旧版本服务的支持？是否知道谁在使用您的服务？
◆部署：要采用何种部署模型？是否要通过 Microsoft Installer 进程和 Visual Studio 部署包进行安装，还是使用 xcopy 就可以满足需要？
◆状态：服务是无状态的吗？是否需要会话？
根据这些非功能性要求，您可以确定哪些宿主是符合您的需求的。为了帮助您做出选择，本章后面的内容将介绍不同的WCF承载环境及其优缺点。注意 由于对自身的运行环境并不了解，因此 WCF 编程模型总是有可能切换到不同宿主，但这并不意味着您必须更改服务实施。首先，您需要在控制台应用程序中进行自承载，以测试并确定服务的原型。
