和傳統的分布式遠程調用一樣，WCF的服務調用借助於服務代理（Service Proxy）。而ChannelFactory<T>則是服務代理的創建者。WCF采用基於終結點（Endpoint）服務消費方式：WCF服務通過一個或者多個終結點暴露給潛在的服務消費者，服務的消費中通過與之匹配的終結點與之交互。在客戶端，我們具有兩種典型的服務代理創建方式，其一是通過諸如SvcUtil.exe這樣的工具導入服務的元數據生成相應的服務代理（一個繼承自ClientBase<T>的類型）代碼和相關配置；其二是直接通過相應的終結點信息（通過代碼指定或者配置）創建ChannelFactory<T>對象，並借助該對象直接進行服務代理的創建。
實際上，即使通過ClientBase<T>對象進行服務調用，其內部也是調用ChannelFactory<T>創建的服務代理。整個ChannelFactory<T>的創建是一項相對復雜並且費時的工作，會涉及很多諸如反射、配置文件的讀取等操作。為了提高服務調用的性能，在.NET 3.5中，WCF在ClientBase<T>中引入了ChannelFactory<T>的緩存機制。
一、如何實現對ChannelFactory<T>的緩存
為了讓讀者對ChannelFactory<T>的緩存機制有一個直觀的認識，我們來做一個簡單的實驗：在一個Console應用中執行如下的代碼，其中CalculatorClient可以看成是本節開篇時自定義的服務代理類。在本例中，先後以相同的方式（調用相同的構造函數，傳入相同的參數）創建並開啟了兩個CalculatorClient對象，然後檢驗它們的ChannelFactory是否是相同的對象。
1: CalculatorClient proxy1 = new CalculatorClient("calculateservice");
2: proxy1.Open();
3: CalculatorClient proxy2 = new CalculatorClient("calculateservice");
4: proxy2.Open();Console.WriteLine("object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory) = {0}",
5: object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory));
輸出結果：
1: object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory) = True
從輸出的結果，可以看出兩個不同的ClientBase<T>對象使用了相同的ChannelFactory<T>對象。這得益於在.NET 3.5中新加入的ChannelFactory<T>的緩存機制。那麼，在WCF客戶端框架內部對ChannelFactory<T>的緩存是如何實現的呢？
實際上，ChannelFactory<T>的緩存實現很簡單，被創建出來的ChannelFactory<T>集合通過ClientBase<T>的一個靜態變量保存起來。我們可以將這個ChannelFactory<T>集合看成是一個字典，字典的值就是ChannelFactory<T>，而鍵則通過下面三個對象派生：
CallbackInstance：以InstanceContext對象表示的對回調對象的封裝；
EndpointConfigurationName：終結點在配制文件中的名稱；
RemoteAddress：終結點的遠程地址，類型為EndpointAddress。
它們分別與ClienBase<T>構造函數中相應的參數相匹配。當調用某個構造函數創建對象的時候，WCF將傳入的三個參數作為Key（如果再構造函數中並未指定相應的參數，會使用默認值，EndpointConfigurationName、CallbackInstance和RemoteAddress的默認值分別為*、null和null），從緩存（靜態變量）中去找匹配的ChannelFactory<T>對象，如果成功找到，則直接返回，否則重新創建，在返回之前將其放入緩存中。
從這個意義上講，多個ClienBase<T>對象能夠重用相同的ChannelFactory<T>對象的前提是它們使用相同的構造函數，並傳入相同的參數被創建。為了驗證這一點，再來做一個實驗，只須要將上面的例子稍加修改，通過另一個重載構造函數來創建CalculatorClient對象。
1: CalculatorClient proxy1 = new CalculatorClient("calculateservice"，new EndpointAddress("http://127.0.0.1:9999/calculateservice");
2: proxy1.Open();
3:
4: CalculatorClient proxy2 = new CalculatorClient("calculateservice");
5: proxy2.Open();
6: Console.WriteLine("object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory) = {0}",
7: object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory));
8:
輸出結果：
1: object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory) = False
實際上，proxy1和proxy2最終使用的終結點地址是相同的（http://127.0.0.1:9999/ calculatorservice），只不過一個是通過代碼指定的，另一個則是通過配置文件配置的。但是，就是因為創建ClienBase<T>時使用了不同的構造函數重載，導致不能重用同一個ChannelFactory<T>對象。
ChannelFactory<T>的重用避免了頻繁地常見ChannelFactory<T>對象，從而獲得更好的性能。在具體的應用中，我們應該盡可能地利用這樣的機制。但是，由於編程人員對ChannelFactory<T>的緩存機制不了解，不知不覺就會使這個緩存機制失效。接下來就來討論這個問題。
二、ChannelFactory<T>緩存機制的失效
總體來講，下面的兩種情況會引起ChannelFactory<T>緩存機制失效。
在構造函數中傳入綁定對象構建ClientBase<T>；
在ClientBase<T>開啟（調用Open方法）之前，訪問如下三個只讀屬性：ChannelFactory、Endpoint和ClientCredential。
為了加深讀者的理解，我們通過實驗的方式來證實上面的兩種說法。為了驗證在構造函數中傳入綁定對象對ChannelFactory<T>緩存機制的影響，寫了如下的代碼：通過Binding和EndpointAddress對象創建ClienBase<T>對象。
1: Binding binding = new BasicHttpBinding();
2: EndpointAddress address = new EndpointAddress("http://127.0.0.1:9999/calculateservice");
3: CalculatorClient proxy1 = new CalculatorClient(binding,address);
4: proxy1.Open();
5: CalculatorClient proxy2 = new CalculatorClient(binding, address);
6: proxy2.Open();
7: Console.WriteLine("object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory) = {0}",
8: object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory));
輸出結果：
1: object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory) = False
接下來，再通過實驗整個在ClientBase<T>開啟（調用Open方法）之前訪問ChannelFactory、Endpoint和ClientCredential三個只讀屬性對ChannelFactory<T>緩存機制的影響。在這裡，以訪問ChannelFactory屬性為例
1: CalculatorClient proxy1 = new CalculatorClient("calculateservice");
2: ChannelFactory<ICalculator> factory = proxy1.ChannelFactory;
3: proxy1.Open();
4: CalculatorClient proxy2 = new CalculatorClient("calculateservice");
5: proxy2.Open();
6: Console.WriteLine("object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory) = {0}",
7: object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory));
8:
輸出結果：
1: object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory) = False
在上面的例子中，在Proxy1的Open方法調用之前，調用了只讀屬性ChannelFactory，並將其賦值到一個臨時變量中，中間根本沒有對ChannelFactory<T>作任何修改，僅僅一次我們認為微不足道的對只讀屬性的訪問就破壞了WCF客戶端框架對ChannelFactory<T>的緩存機制。
三、如何有效利用ChannelFactory<T>的緩存機制
為了能夠充分利用ChannelFactory<T>的緩存機制，獲得更好的服務調用性能，我們可以得出以下兩個最佳實踐：
避免通過人為指定綁定對象創建ClientBase<T>對象，應該盡可能使用配置的綁定信息；
避免在ClientBase<T>開啟之前讀取ChannelFactory、Endpoint和ClientCredential三個屬性，或者在創建ClientBase<T>之後顯式調用Open方法開啟ClientBase<T>對象。
注：部分內容節選自《WCF技術剖析（卷1）》第八章:客戶端（Clients）
