CF現(xiàn)在還是有很多人用的，不知道你現(xiàn)在在使用嗎？如果你不用的話你就是落伍的人了，我們就WCF承載環(huán)境問題分析一下吧。Microsoft 在確保服務開發(fā)人員無需過分考慮WCF承載環(huán)境方面所做的努力是值得肯定的。ServiceHost 排除了所有技術性的難點，使您可以重點關注服務邏輯，而不必過多地考慮如何承載服務。您必須根據(jù)自己的具體要求選擇一個宿主。WCF 主要是作為編程模型而編寫的，其主要設計目的之一是為了實現(xiàn)“宿主的不可知”。ServiceHost 不關心自身在哪里被實例化，只要您希望服務可被訪問時它正在運行即可。也就是說，它需要一個運行 .NET 應用程序域的進程。

#T#在選擇應用程序類型時，必須考慮某些特定要求（例如，程序屬于控制臺應用程序還是 WinForms 應用程序等）。ServiceHost 必須被實例化才能提供運行服務所需的WCF承載環(huán)境。典型的 .NET 應用程序（例如，控制臺應用程序和 WinForms 應用程序）通常運行在用戶桌面計算機上。這些環(huán)境并非始終運行，它們可以承載您的服務，但卻并非典型的適用于企業(yè)的宿主。我們認為適用于企業(yè)的宿主應該能夠支持更大規(guī)模的面向服務的體系結構，在這種體系結構中，多個系統(tǒng)需要依賴服務所公開的關鍵業(yè)務功能。這些適用于企業(yè)的宿主通常能夠滿足諸如高可用性的要求。因此，我們不能將控制臺或 WinForms 應用程序做為適用于企業(yè)的宿主。

通常情況下，服務運行在服務器上，并由操作員進行管理和操作。管理服務器的操作員一般不希望在服務器重新啟動時手動啟動控制臺應用程序或 WinForms 應用程序。為了讓服務應用程序能夠在數(shù)據(jù)中心運行，對于企業(yè)級面向服務的情況來說，***可行的方案就是在 IIS 上承載服務，或將其作為一項 Windows 服務。

有時，您需要在用戶的桌面計算機上實現(xiàn)進程間通信。在這種情況下，只有當用戶使用應用程序時，服務才是活動的。需要進行進程間通信的典型應用程序就是控制臺應用程序和 WinForms 應用程序。這些應用程序適合承載這些類型的服務。

要能夠確定哪種宿主最適合您的情況，您應當考慮到非功能性要求。一般來講，非功能性要求規(guī)定了應用程序的技術要求，以確保其達到應用程序要求的質量和可維護性。對于 WCF 應用程序來說，非功能性要求實際涉及以下內容：
◆可用性：希望何時能夠訪問您的服務？
◆可靠性：當服務由于某些原因出現(xiàn)中斷時會發(fā)生什么問題？這將如何影響服務的其他使用者？
◆可管理性：是否需要便捷地了解承載 WCF 服務的宿主上所發(fā)生的情況？
◆版本控制：是否需要提供對舊版本服務的支持？是否知道誰在使用您的服務？
◆部署：要采用何種部署模型？是否要通過 Microsoft Installer 進程和 Visual Studio 部署包進行安裝，還是使用 xcopy 就可以滿足需要？
◆狀態(tài)：服務是無狀態(tài)的嗎？是否需要會話？

根據(jù)這些非功能性要求，您可以確定哪些宿主是符合您的需求的。為了幫助您做出選擇，本章后面的內容將介紹不同的WCF承載環(huán)境及其優(yōu)缺點。注意 由于對自身的運行環(huán)境并不了解，因此 WCF 編程模型總是有可能切換到不同宿主，但這并不意味著您必須更改服務實施。首先，您需要在控制臺應用程序中進行自承載，以測試并確定服務的原型。