WCF(五) 深入理解绑定
?
適用于本機(jī)WCF-WCF交互性能最佳的綁定：
允許跨主機(jī)，但只能用于部署同一臺(tái)主機(jī)上，不能訪問(wèn)命名管道
?
netNamePipeBinding總結(jié)
?
?
?
一?WCF與SOA
SOA是一種通過(guò)為所有軟件提供服務(wù)外觀，并將這些服務(wù)的WSDL集中發(fā)布到一個(gè)地方的一種組織企業(yè)軟件的方法。它通過(guò)使用明確定義的接口通過(guò)跨越邊界傳遞消息來(lái)讓多個(gè)自治的服務(wù)協(xié)同工作。SOA的真正價(jià)值是——允許開發(fā)者從代碼中抽取出公共基礎(chǔ)功能的實(shí)現(xiàn)，更多地關(guān)注業(yè)務(wù)邏輯和需要的功能特性。在開發(fā)SOA應(yīng)用程序時(shí)，我們能夠?qū)崿F(xiàn)服務(wù)代碼與客戶端使用技術(shù)與平臺(tái)的解耦，也與并發(fā)管理、事務(wù)傳播和管理以及通信可靠性、協(xié)議和模式無(wú)關(guān)。
SOA的4個(gè)主要設(shè)計(jì)原則以及在WCF中的具現(xiàn)如下：
- 邊界是明確的?SOA系統(tǒng)中的每個(gè)服務(wù)都必須被限定在某個(gè)明確的邊界之內(nèi)。服務(wù)邊界指的就是服務(wù)的公共接口與其內(nèi)部實(shí)現(xiàn)之間有清晰的界線。WCF服務(wù)的功能是通過(guò)定義明確的接口進(jìn)行表達(dá)的，外部調(diào)用者和WCF服務(wù)通信的唯一方式就是通過(guò)這個(gè)接口，客戶端無(wú)法知道服務(wù)的實(shí)現(xiàn)細(xì)節(jié)，以達(dá)到信息隱藏和解耦的目的。
- 服務(wù)是自治的?自治的服務(wù)對(duì)于版本問(wèn)題、部署問(wèn)題和安裝問(wèn)題來(lái)說(shuō)應(yīng)該是獨(dú)立的不會(huì)影響整個(gè)SOA系統(tǒng)。服務(wù)的運(yùn)行不需要依賴任何外部服務(wù)或者組件。我們?yōu)閃CF擴(kuò)展功能，只能通過(guò)編寫新的接口來(lái)實(shí)現(xiàn)。
- 采用標(biāo)準(zhǔn)的契約定義和通信協(xié)議?服務(wù)通過(guò)契約而不是實(shí)現(xiàn)進(jìn)行通信，服務(wù)契約定義和通信協(xié)議都是行業(yè)標(biāo)準(zhǔn)。WCF對(duì)常用協(xié)議和主流編碼格式提供支持。
- 服務(wù)是自解釋的?服務(wù)的內(nèi)容必須是自解釋的，服務(wù)必須以某種方式告訴客戶端服務(wù)的功能。WCF提供了強(qiáng)類型的契約，并會(huì)根據(jù)綁定來(lái)生成WSDL文檔。
以上原則比較抽象，為了更好的設(shè)計(jì)SOA程序，應(yīng)該遵守以下原則：
- 服務(wù)是安全的?服務(wù)與客戶端必須使用安全的通信。
- 服務(wù)在系統(tǒng)中應(yīng)保持一致的狀態(tài)?執(zhí)行客戶端請(qǐng)求時(shí)，禁止進(jìn)行部分替換條件，即系統(tǒng)提供服務(wù)給客戶端調(diào)用后必須保持一致的狀態(tài)，如果有錯(cuò)誤發(fā)生，系統(tǒng)狀態(tài)不應(yīng)該部分受到影響，必須被恢復(fù)到一致的狀態(tài)。
- 服務(wù)是線程安全的?服務(wù)必須設(shè)計(jì)為線程安全，才能維持多線程的并發(fā)訪問(wèn)。
- 服務(wù)是可靠的?客戶端以確定的方式獲知服務(wù)是否接收了消息。
- 服務(wù)是健壯的?服務(wù)與它的錯(cuò)誤分離能夠防止錯(cuò)誤影響服務(wù)本身或其它服務(wù)。
可選原則如下：
- 服務(wù)是平臺(tái)無(wú)關(guān)的?服務(wù)應(yīng)該能夠被任意的客戶端調(diào)用，而不用考慮客戶端技術(shù)。
- 服務(wù)的規(guī)模不可變?不管客戶端有多少，也不管服務(wù)的承載是多少，服務(wù)代碼都應(yīng)該相同。
- 服務(wù)是可用的?服務(wù)總是能夠接受客戶端的請(qǐng)求，而不會(huì)因此停止。
- 服務(wù)是及時(shí)響應(yīng)的和受限的?服務(wù)開始處理客戶端的請(qǐng)求時(shí)，不能讓客戶端等待的太久。服務(wù)執(zhí)行的任意操作應(yīng)該盡可能短，不能消耗太多時(shí)間去處理客戶端的請(qǐng)求。
微軟的WCF框架中的基礎(chǔ)設(shè)施為我們解決了以上原則中的多數(shù)，使我們可以將關(guān)注點(diǎn)重新回歸的業(yè)務(wù)邏輯層上。面向服務(wù)技術(shù)展示出的魅力，促使越來(lái)越多的開發(fā)者投入其中。
二 WCF模型
WCF的體系架構(gòu)如下：
WCF的客戶端與服務(wù)端模型如下：
1 地址?
WCF的每一個(gè)服務(wù)都有唯一的地址。地址包括服務(wù)位置和傳輸協(xié)議（傳輸樣式）。服務(wù)位置包括目標(biāo)機(jī)器名、站點(diǎn)、網(wǎng)絡(luò)、端口、管道或隊(duì)列，以及一個(gè)可選的特定路徑或者URI。
地址常用格式為：[基地址]/[可選的URI]，如“net.tcp://localhost:8081/MyService”。
基地址常用格式為：[傳輸協(xié)議]://[機(jī)器名或域名][:可選端口]，如“net.tcp://localhost:8081”。
WCF支持多種傳輸樣式：
- HTTP?采用http、https協(xié)議進(jìn)行傳輸，默認(rèn)端口號(hào)80。
- TCP?采用net.tcp協(xié)議進(jìn)行傳輸，默認(rèn)地址為808。
- Peer?network（對(duì)等網(wǎng)）?采用net.p2p進(jìn)行傳輸，采用Windows的對(duì)等網(wǎng)傳輸機(jī)制。
- IPC（內(nèi)部進(jìn)程通信）?采用net.pipe進(jìn)行傳輸，使用Windows的命名管道機(jī)制，只能接收來(lái)自同一臺(tái)機(jī)器的調(diào)用，且每臺(tái)機(jī)器只能打開一個(gè)命名管道。
- MSMQ?采用net.msmq進(jìn)行傳輸，使用Windows的MSMQ機(jī)制，必須指定隊(duì)列名，如果是處理私有隊(duì)列，則必須指定隊(duì)列類型。
2 綁定
綁定將通信模式與交互方式直接的組合進(jìn)行規(guī)范，將這些通信特征合理地組合在一起。一個(gè)綁定封裝了諸如傳輸協(xié)議、消息編碼、可靠性、安全性、事務(wù)傳播以及互操作性等相關(guān)選項(xiàng)的組合，使得它們保持一致。
WCF定義了六種常用的綁定：
- 基本綁定?由BasicHttpBinding類提供，將WCF服務(wù)公開為Web服務(wù)。
- TCP綁定?由NetTcpBinding類提供，使用TCP協(xié)議通信，支持多種特性，包括可靠性、事務(wù)性、安全性及WCF之間通信的優(yōu)化，缺點(diǎn)是客戶端必須使用WCF。
- IPC綁定?由NetNamedPipeBinding類提供，使用命名管道為同一機(jī)器的通信進(jìn)行傳輸，支持的特性與TCP綁定類似，是性能和安全性最佳的綁定。
- Web服務(wù)綁定?由WSHttpBinding類提供，WS綁定使用HTTP或HTTPS進(jìn)行傳輸，提供了諸如可靠性、事務(wù)性與安全性在內(nèi)的多種特性，這些特性遵循WS-*標(biāo)準(zhǔn)，該綁定被設(shè)計(jì)用來(lái)與支持WS-*標(biāo)準(zhǔn)的系統(tǒng)進(jìn)行互操作。
- WS雙向綁定?由WSDualHttpBinding類提供，支持雙向通信。
- MSMQ綁定?由NetMsmqBinding類提供，使用MSMQ進(jìn)行傳輸。
常用綁定的傳輸協(xié)議與編碼格式如下：
| ?名字? | ?傳輸協(xié)議? | ?編碼格式? | ?互操作性? |
| ?BasicHttpBinding? | ?HTTP/HTTPS? | ?Text,MTOM? | ?yes |
| ?NetTcpBinding | ?TCP | ?Binary | ?no |
| ?NetNamedPipeBinding? | ?IPC | ?Binary? | ?no |
| ?WSHttpBinding? | ?HTTP/HTTPS? | ?Text,MTOM? | ?yes |
| ?WSDualHttpBinding? | ?HTTP | ?Text,MTOM? | ?no |
| ?NetMsmqBinding? | ?MSMQ? | ?Binary? | ?no |
注意：TCP、IPC和MSMQ綁定使用的二進(jìn)制編碼器是WCF專有的，不要試圖為其編寫針對(duì)其他平臺(tái)的自定義解析器。
3 契約?
WCF的所有服務(wù)都公開為契約，契約與平臺(tái)無(wú)關(guān)，是描述服務(wù)功能的標(biāo)準(zhǔn)方式。WCF包含4類契約：
- 服務(wù)契約?描述了客戶端能夠執(zhí)行的服務(wù)操作。
- 數(shù)據(jù)契約?定義了與服務(wù)交互的數(shù)據(jù)類型。
- 錯(cuò)誤契約?定義了服務(wù)拋出的錯(cuò)誤，以及服務(wù)處理錯(cuò)誤和傳遞錯(cuò)誤到客戶端的方式。
- 消息契約?消息契約允許服務(wù)直接與消息交互，用于定制專有的消息格式，也意味著要自己的應(yīng)用程序上下文，因?yàn)闀?huì)增加代碼的復(fù)雜度，所以不屬于常見用法。
4 終結(jié)點(diǎn)
終結(jié)點(diǎn)是WCF進(jìn)行通信的唯一手段，ChannelFactory<T>本質(zhì)上是通過(guò)制定的終結(jié)點(diǎn)創(chuàng)建用于進(jìn)行服務(wù)調(diào)用的服務(wù)代理。終結(jié)點(diǎn)在WCF體系中通過(guò)Systtm.ServiceModel.Description.ServiceEndpoint類型表示，其包含三個(gè)核心屬性——地址、綁定、契約。終結(jié)點(diǎn)是用來(lái)發(fā)送和接收消息的構(gòu)造，終結(jié)點(diǎn)是真正意義上的接口，它包含了一個(gè)對(duì)象接口所需的全部信息。每個(gè)服務(wù)至少必須公開一個(gè)業(yè)務(wù)終結(jié)點(diǎn)，每個(gè)終結(jié)點(diǎn)有且只能擁有一個(gè)契約。服務(wù)上的所有終結(jié)點(diǎn)都包含了唯一的地址，而一個(gè)單獨(dú)的服務(wù)則可以公開多個(gè)終結(jié)點(diǎn)。這些結(jié)點(diǎn)可以使用相同或不同的綁定，公開相同或不同的契約。
5 元數(shù)據(jù)
服務(wù)的元數(shù)據(jù)描述服務(wù)的特征，外部實(shí)體需要了解這些特征以便與該服務(wù)進(jìn)行通信。服務(wù)的元數(shù)據(jù)包括XML、架構(gòu)文檔（用于定義服務(wù)的數(shù)據(jù)協(xié)定）和WSDL文檔（用于描述服務(wù)的方法）。啟用元數(shù)據(jù)后，WCF通過(guò)檢查服務(wù)及其終結(jié)點(diǎn)自動(dòng)生成服務(wù)的元數(shù)據(jù)。
6 上下文
WCF上下文將服務(wù)宿主與公開本地CLR類型為服務(wù)的上下文組合在一起，上下文是服務(wù)實(shí)例最核心的執(zhí)行范圍，上下文可以為空，即不包含任何服務(wù)實(shí)例。
7 宿主
WCF服務(wù)類不能憑空存在，每個(gè)WCF服務(wù)類必須托管在某個(gè)宿主進(jìn)程中。單個(gè)宿主進(jìn)程可以托管多個(gè)服務(wù)，而相同的服務(wù)類型也可以托管在多個(gè)宿主進(jìn)程中，如果服務(wù)與客戶端駐留在相同的進(jìn)程中，則稱為進(jìn)程內(nèi)托管。常用宿主如下：
- Web站點(diǎn)
- Windows窗體應(yīng)用程序
- Windows服務(wù)
- Windows激活服務(wù)（WAS）
WCF宿主體系結(jié)構(gòu)如下：
? 每個(gè).NET宿主進(jìn)程都包含了多個(gè)應(yīng)用程序域，每個(gè)應(yīng)用程序域包含零到多個(gè)宿主實(shí)例，每個(gè)服務(wù)宿主實(shí)例專門對(duì)于于一個(gè)特殊的服務(wù)類型。因此，創(chuàng)建一個(gè)宿主實(shí)例，實(shí)際上就是為對(duì)應(yīng)于基地址的宿主機(jī)器的類型注冊(cè)一個(gè)包含了所有終結(jié)點(diǎn)的服務(wù)宿主實(shí)例。每個(gè)服務(wù)宿主實(shí)例擁有零到多個(gè)上下文。一個(gè)上下文可以與零個(gè)或一個(gè)服務(wù)實(shí)例關(guān)聯(lián)。
8 代理?
WCF不允許客戶端直接與服務(wù)交互，客戶端使用代理將調(diào)用轉(zhuǎn)發(fā)給服務(wù)。即使對(duì)象是本地的，WCF仍然使用遠(yuǎn)程編程模型的實(shí)例化方式，并且使用代理。
三 WCF體系架構(gòu)
（一） 通道棧模型
WCF通道模型：
無(wú)論交互的另一方的具體位置在哪里，WCF都會(huì)為消息的發(fā)送和接收建立一套完整的消息管道，這個(gè)消息管道被成為通道棧。通道棧中的每一個(gè)通道組件都有機(jī)會(huì)對(duì)消息進(jìn)行處理，而整個(gè)通道棧是可編輯且可插入的，這就確保WCF的通道模型具有相當(dāng)大的靈活性。另外，WCF通道模型是完全和上層程序隔離的，任何一個(gè)服務(wù)/客戶端都可以輕松配置到不同的通道模型上去。通道模型可以被分為兩部分——協(xié)議通道和傳輸通道。一個(gè)通道棧可以擁有任意多個(gè)協(xié)議通道，但一般只擁有一個(gè)傳輸通道。傳輸通道負(fù)責(zé)把消息進(jìn)行編碼并且發(fā)送到遠(yuǎn)端，編碼時(shí)需要使用調(diào)用棧的編碼器。一般而言，協(xié)議通道負(fù)責(zé)維護(hù)消息的非業(yè)務(wù)邏輯功能，包括：事務(wù)、日志、可靠消息、安全性等。開發(fā)者可以自定義協(xié)議通道并插入到通道棧中。在一個(gè)通道棧中，必須包含至少一個(gè)傳輸通道和編碼器，傳輸通道負(fù)責(zé)把消息編碼和發(fā)送。（傳輸通道會(huì)嘗試從BindingContext對(duì)象中查找編碼器，如果沒(méi)有找到則會(huì)使用默認(rèn)的編碼器，在完成消息的編碼之后，傳輸通道負(fù)責(zé)把消息發(fā)送到遠(yuǎn)端，不同的傳輸通道將使用不同的傳輸協(xié)議，如HTTP、TCP、IPC等。）
WCF體系體系架構(gòu)是基于攔截機(jī)制的，通過(guò)代理與客戶端的交互意味著WCF總是處于服務(wù)與客戶端之間，攔截所有的調(diào)用，執(zhí)行調(diào)用前和調(diào)用后的處理。當(dāng)代理將調(diào)用棧幀序列化到消息中，并將消息通過(guò)通道鏈向下傳遞時(shí)，WCF就開始執(zhí)行攔截。通道相當(dāng)于一個(gè)攔截器，目的在于執(zhí)行一個(gè)特定的任務(wù)。每個(gè)客戶端通道都會(huì)執(zhí)行消息的調(diào)用前處理。鏈的組成與結(jié)構(gòu)主要依賴于綁定。客戶端的最后一個(gè)通道是傳輸通道，根據(jù)配置的傳輸方式發(fā)送消息給宿主。在宿主端，消息同樣通過(guò)通道鏈進(jìn)行傳輸，它會(huì)對(duì)消息執(zhí)行宿主端的調(diào)用前處理。宿主端的第一個(gè)通道是傳輸通道，接收傳輸過(guò)來(lái)的消息。隨后的通道執(zhí)行不同的任務(wù)。宿主端的最后一個(gè)通道負(fù)責(zé)將消息傳遞給分發(fā)器。分發(fā)器將消息轉(zhuǎn)換到一個(gè)棧幀，并調(diào)用服務(wù)實(shí)例。事實(shí)上，服務(wù)會(huì)被本地客戶端——分發(fā)器調(diào)用。客戶端與服務(wù)端的攔截器確保了它們能夠獲得運(yùn)行時(shí)環(huán)境，以便于它們執(zhí)行正確的操作。
服務(wù)實(shí)例會(huì)執(zhí)行調(diào)用，然后將控制權(quán)返回給分發(fā)器。分發(fā)器負(fù)責(zé)將返回值以及錯(cuò)誤信息轉(zhuǎn)換為一條返回消息。分發(fā)器獲得控制權(quán)，執(zhí)行的過(guò)程剛好相反：分發(fā)器通過(guò)宿主端通道傳遞消息，執(zhí)行調(diào)用后的處理，如管理事務(wù)、加密等。為了執(zhí)行客戶端調(diào)用后的處理，包括解密、解碼、提交或取消事務(wù)等任務(wù)，傳輸通道會(huì)將返回消息發(fā)送到客戶端通道。最后一個(gè)通道將消息傳遞給代理。代理將返回消息轉(zhuǎn)化到棧幀，然后將控制權(quán)返回給客戶端。
（二） 消息交換模式
WCF定義的6種消息交換模式：
1 ?請(qǐng)求-響應(yīng)模式
客戶端向服務(wù)器發(fā)送一個(gè)請(qǐng)求，等待服務(wù)器的響應(yīng)，等待時(shí)間是一個(gè)預(yù)定義的時(shí)間，是最常用的模式。WCF中通過(guò)在接口上定義[ServiceContact]和[OperationContract]來(lái)表示請(qǐng)求和響應(yīng)的細(xì)節(jié)。
2?單工消息處理模式
? 只按一個(gè)方向把消息從客戶端發(fā)送到服務(wù)器，服務(wù)器只處理消息，但不返回處理結(jié)果。這種模式最大的價(jià)值在于能夠?qū)崿F(xiàn)異步通信以及保證消息傳送環(huán)境的能力，利用單工模式，可以通過(guò)MSMQ來(lái)發(fā)送消息。WCF通過(guò)把[OperationContract]的IsOneWay設(shè)置為True，來(lái)實(shí)現(xiàn)單工模式。
3?雙工消息處理模式
? 客戶端和服務(wù)端相互調(diào)用，客戶端和服務(wù)端的角色也在不斷交替。為了完成回調(diào)，服務(wù)端必須知道回調(diào)操作的方法簽名，而且該回調(diào)操作將同時(shí)出現(xiàn)在客戶端和服務(wù)端中。為此，在WCF中實(shí)現(xiàn)雙工模式，需要在它的綁定信息中說(shuō)明，在客戶端實(shí)現(xiàn)的方法簽名需要在服務(wù)層定義，同時(shí)需要這些方法在客戶端實(shí)現(xiàn)，這樣服務(wù)端才能調(diào)用他們。
4?流模式
客戶端發(fā)起一個(gè)請(qǐng)求，請(qǐng)求一個(gè)非常大的數(shù)據(jù)，服務(wù)把數(shù)據(jù)分割為小塊，并把這些數(shù)據(jù)塊按使用順序逐個(gè)地發(fā)送給客戶端。在這種模式下，一個(gè)數(shù)據(jù)請(qǐng)求緊跟著多個(gè)響應(yīng)，每個(gè)響應(yīng)都包含了全部數(shù)據(jù)的一個(gè)子集，由發(fā)送者在最后的消息中標(biāo)識(shí)數(shù)據(jù)流的結(jié)束，以告知客戶端不需要繼續(xù)等待更多的數(shù)據(jù)。
5 發(fā)布-訂閱模式
發(fā)布-訂閱模式中，發(fā)布者不關(guān)心是否有訂閱者，它只關(guān)心從自己的系統(tǒng)中發(fā)送數(shù)據(jù)。這種模式表示了一種驅(qū)動(dòng)方法，即發(fā)布者在客戶端應(yīng)用程序中啟動(dòng)一個(gè)事件，客戶端針對(duì)這些事件作出響應(yīng)。WCF不直接支持發(fā)布-訂閱模式，而是利用與雙工模式相同的構(gòu)造來(lái)實(shí)現(xiàn)發(fā)布-訂閱模式。發(fā)布-訂閱模式的實(shí)現(xiàn)通過(guò)一個(gè)訂閱服務(wù)，此服務(wù)在內(nèi)存中保存訂閱者回調(diào)通道的引用。當(dāng)服務(wù)需要向所有訂閱者發(fā)送數(shù)據(jù)時(shí)，它便循環(huán)地訪問(wèn)這些訂閱者，并調(diào)用一個(gè)方法來(lái)發(fā)送數(shù)據(jù)。這里沒(méi)有使用輪詢的方法，是因?yàn)橛嗛喺咂鹚拗鞯淖饔?#xff0c;它在等待被服務(wù)調(diào)用的方法。
6 隱式順序調(diào)用模式
在該模式中，客戶端以某個(gè)順序調(diào)用服務(wù)端的多個(gè)操作。隱式順序調(diào)用模式允許定義邏輯順序中最后調(diào)用的方法，此后客戶端將不能再調(diào)用其它方法。WCF使用[OperationContract]定義操作的調(diào)用順序，把方法的IsInitiating設(shè)置為false，可以起動(dòng)一個(gè)會(huì)話；把IsTerminating設(shè)置為true，表示調(diào)用這個(gè)方法以結(jié)束會(huì)話。（另一種實(shí)現(xiàn)方式，是借助工作流。）
（三） 通道形狀
WCF中通過(guò)通道形狀來(lái)實(shí)現(xiàn)具體的消息交換模式，通道形狀則是只繼承自IChannel的一組接口，WCF會(huì)根據(jù)上層協(xié)議來(lái)自動(dòng)選取需要的通道形狀。消息交換模式與通信協(xié)議是密切相關(guān)的，通過(guò)在傳輸通道上層添加特殊的協(xié)議通道，可以強(qiáng)制使用某種傳輸通道不支持的消息交換模式。（OneWayBindingElement單工模式和CompositeDuplexElement雙工模式）
（四） 通道管理器
WCF中實(shí)現(xiàn)了兩類通道管理器，分別實(shí)現(xiàn)IChannelListener<T>和IChannelFactory<T>。IChannelListener<T>負(fù)責(zé)接收端的信息交換控制工作，負(fù)責(zé)偵聽消息、建立通道棧，并且通過(guò)通道棧頂層通道的引用，它可以獨(dú)立于它的通道棧而關(guān)閉。ServiceHost內(nèi)部就是使用了IChannelListener<T>來(lái)實(shí)現(xiàn)通道的管理。IChannelListener<T>負(fù)責(zé)在發(fā)送端控制消息的發(fā)送以及創(chuàng)建并管理通道棧，并且負(fù)責(zé)關(guān)閉通道棧，一般使用ClientBase<T>來(lái)代替直接使用IChannelFactory<T>。
（五）ICommunicationObject
WCF的ICommunicationObject定義了狀態(tài)機(jī)制的統(tǒng)一模型。基本所有的通信組件，包括通道和通道管理器都實(shí)現(xiàn)了ICommunicationObject。ICommunicationObject用于狀態(tài)管理，其定義了改變狀態(tài)的方法、狀態(tài)改變觸發(fā)的事件已經(jīng)當(dāng)前狀態(tài)的獲取。ICommunicationObject的State為CommunicationState枚舉類型，用于表示“狀態(tài)”，有6種可用狀態(tài)，分別為：Created（已創(chuàng)建），Opening（打開中），Opened（已打開），Closing（關(guān)閉中），Closed（已關(guān)閉），Faulted（錯(cuò)誤），其狀態(tài)變化順序如下：
? 由上圖可見，狀態(tài)機(jī)的改變是只進(jìn)的，狀態(tài)的改變是不可逆的。
四 WCF程序的開發(fā)步驟
五 編碼規(guī)范
- 應(yīng)該將服務(wù)代碼放入到類庫(kù)中，而不是放到宿主程序中。
- 不要為服務(wù)類型提供帶參數(shù)的構(gòu)造器，除非托管的服務(wù)是明確的單例服務(wù)。
- 在相關(guān)綁定中啟用可靠性。
- 為契約提供有意義的命名空間。
- 對(duì)于運(yùn)行在Windows XP或Windows Server 2003上的局域網(wǎng)應(yīng)用程序，最好選用自托管，而不是IIS托管。
- 在Windows Vista和Windows Server 2008或更高版本中，最好使用WAS托管，而不是自托管。
- 啟用元數(shù)據(jù)交換。
- 為客戶端配置文件中的所有終結(jié)點(diǎn)命名。
- 盡量自己編寫配置文件。
- 不要復(fù)制代理的代碼，可以將代理分解到單獨(dú)的類庫(kù)中。
- 及時(shí)關(guān)閉和釋放代理。
?
? ? ? ? ? ? ? from-http://www.cnblogs.com/MeteorSeed/archive/2012/04/24/2399455.html
轉(zhuǎn)載于:https://www.cnblogs.com/PEPE/p/3308249.html
總結(jié)
以上是生活随笔為你收集整理的WCF(五) 深入理解绑定的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 40. Combination Sum
- 下一篇： 转载： 我如何使用 Django + V