概述
用戶代碼不能直接創建通道；這些工作由特定的工廠類型完成。雖然這些工 廠對象不是通道，但是通常它們也被認為是通道層的一部分。在第6章“通道” 裡，我引入了設計模式【老徐備注】（Erich Gamma等, Addison- Wesley, 1995）的概念，並把這種特殊的類型的稱為通道工廠。在Windows Communication Foundation (WCF)的類型系統中，通道工廠有特殊的名字，這些 名稱與發送者和接收者的命名不同。在接收端，這些類型被稱作通道偵聽器 （channel listeners）。在發送端，這些類型被稱作通道工廠（channel factories）. 雖然通道偵聽器和通道工廠擁有相同的特性和功能，但是它們卻 包含不同的對象和行為模型。當放在一起的時候，它們被稱作通道管理器。本章 就會介紹通道管理器的內部類型：通道偵聽器和通道工廠。你會了解這些類型的 基本知識，以及它們的對象模型，然後我們會學習如何創建自定義通道的例子。 本章會給出部分代碼，完整的代碼直到下一章“綁定”才會全部給出，因為創建 通道要使用到Binding。。
通道是WCF程序實現消息功能的物理方式，而通道工廠和通道偵聽器是WCF程 序創建消息功能的方式。正如沒有萬能的通道類型，也沒有萬能的通道工廠或者 通道偵聽器。通道可以根據功能來劃分（例如，WS-ReliableMessaging、 TCP/IP傳輸等等），通道管理器也可以更具他們創建的通道功能劃分，比如， WS-ReliableMessaging通道是由WS- ReliableMessaging通道管理器創建的，而 且相同的通道管理器不會重復創建通道。
這並不是說一個通道管理器只創建一種類型的通道。恰恰相反，通道管理器 可以創建多種不同的通道，但是這些通道會駐留在一個特定的功能組裡。很明顯 的一點就是，通道管理器創建的通道類型只是形狀方面存在差別。有時候，通道 管理器甚至可以創建類型和形狀一樣的通道（例如，雙工通道）
通道管理器與通道擁有許多相同的特性。因為通道在運行時會組織在一個堆 棧裡，所以通道管理器也會被組織到對站立。某種意義上說，堆棧裡的通道管理 器的組織情況就是通道的組織情況。通道管理器實現了ICommunicationObject接 口，而且擁有第6章裡所述的通道狀態機。更進一步說，它們也實現了查詢可用 通道的機制。
通道管理器的概念
所有的通道管理器都繼承自一個抽象基類型： System.ServiceModel.Channels. ChannelManagerBase。類名沒有體現出這個類 型的目的，從名字上看，一種猜測就是ChannelManagerBase類型是追蹤通道管理 器創建的通道的一種方式。在早期的WCF（那時被稱為Indigo），確實是這個目 的。早期設計使得通道的狀態和生命周期與通道管理器對象的狀態和生命周期緊 密耦合在一起。例如，當一個通道管理器關閉的時候，它也會關閉所有創建的通 道實例。
對於發送者可以使用這個模型，但是對於接收者來說就不是那麼完美了，因 為接收者對於一個統一資源標識符（URI）只能有一個通道偵聽器。接收者經常 需要創建新的通道偵聽器堆棧，並且關閉現有的偵聽器堆棧。因為關閉一個接收 通道可能執行一些其它工作（比如，WS-RM消息，提交或中斷事務等等），所以 關閉對應的通道偵聽器就需要花費很長時間。如果通道和通道偵聽器沒有緊密耦 合，就可以關閉當前的偵聽器，完成當前的工作，然後啟動一個新的通道偵聽器 去處理新的消息。WCF團隊在第一個版本裡使用了這個模型，主要是因為它能給 接收程序帶來更好的吞吐量。
本質上，早期的通道管理器的概念在發送者上依然有效。 ChannelManagerBase 類型不在管理通道的工作，作為替代，在通道工廠的類型 層次中，它們會負責管理通道。因為這個改變，ChannelManagerBase類型就成為 一個強制通道管理器實現通道狀態機、實現查詢機制、傳遞Binding超時屬性給 通道的簡單方式。
