WCF支持對Stream對象的操作，尤其對于傳遞size過大的消息而言，如要考慮傳遞消息的效率，WCF推薦通過Stream進(jìn)行操作。

然而，WCF對于Stream操作規(guī)定了一些限制，在我們編寫相關(guān)程序時，需要特別注意：
1、綁定的限制
如 果需要使用Stream操作，可以使用的綁定只能是BasicHttpBinding，NetTcpBinding以及 NetNamedPipeBinding。此外，在使用Stream操作時，不能使用Reliable Messaging。如果考慮到消息安全，則此方式是不可取的。

2、對Stream對象的限制
要作為服務(wù)操作所傳遞的消息對象，這樣的對象必須是可序列化的。遺憾的是，FileStream類的定義卻是不支持序列化的，我們能夠使用的Stream對象，包括Stream，MemoryStream等。使用Stream類對象是大多數(shù)Stream操作的首選。

一個有趣的現(xiàn)象是FileStream與Stream類型的轉(zhuǎn)換。例如在服務(wù)契約的操作中，有如下的實(shí)現(xiàn)：

public?Stream?TransferDocument(Document?document)
{
???? FileStream?stream?=?new?FileStream
???????????????????????????? (document.LocalPath,?FileMode.Open,?FileAccess.Read);
?????return?stream;
}

?

注意，操作TransferDocument()的返回類型為Stream，而方法的實(shí)現(xiàn)中，返回的對象則為FileStream類型。由于Stream類是FileStream類的父類，這樣的實(shí)現(xiàn)沒有問題。

然而，在客戶端調(diào)用該操作時，卻不能將操作的返回值賦給FileStream類型的對象，如下所示：

FileStream?stream?=?m_service.TransferDocument(doc);

此時獲得的Stream對象則為null。因而，我們只能這樣調(diào)用操作：

Stream?stream?=?m_service.TransferDocument(doc);

但是，還有一個奇怪的問題是WCF并不支持Stream對象Length屬性的序列化，也就是說，在客戶端我們不能使用服務(wù)操作返回的Stream對象的Length屬性。諸如stream.Length的調(diào)用會拋出NotSupportedException異常。

3、TransferMode的限制

若 要使用Stream操作，必須修改綁定的TransferMode屬性。該屬性的默認(rèn)值為Buffered。我們應(yīng)該根據(jù)操作中Stream對象的參數(shù)類 型，以決定TransferMode的值分別為Streamed、StreamedRequest或者StreamedResponse。

4、MaxReceivedMessageSize的限制

MaxReceivedMessageSize 屬性的默認(rèn)值為64kb，如果傳遞的Stream對象一旦超過了MaxReceivedMessageSize屬性的設(shè)置值，則客戶端在操作該對象時，就 會出現(xiàn)CommunicationException異常。因此，我們應(yīng)根據(jù)實(shí)際需要設(shè)置MaxReceivedMessageSize的值。 MaxReceivedMessageSize屬性的取值范圍為1-9223372036854775807（Int32.MaxValue）。如果設(shè)置 值不在該范圍之內(nèi)，則無法通過編譯。編程方式設(shè)置為：

binding.MaxReceivedMessageSize?=?120000;

配置文件的設(shè)置方式為：

<binding?…… maxReceivedMessageSize="120000"/>

5、操作參數(shù)的限制

WCF對包含了Stream對象的操作參數(shù)進(jìn)行嚴(yán)格的限制，它只允許這樣的操作只能包含一個Stream對象，這里所謂的一個Stream對象，是包含return對象，out和ref對象在內(nèi)的。也就是說如下的操作定義都是錯誤的：

void?Transfer(Stream?s1,?Stream?s2);
void?Transfer(Stream?s1,?out?Stream?s2);
void?Transfer(Stream?s1,?ref?Stream?s2);
Stream?Transfer(Stream?stream);

如果定義了這樣的操作，則會出現(xiàn)運(yùn)行時錯誤。

6、實(shí)例激活類型的限制

由 于Stream操作受到綁定的限制，只能使用BasicHttpBinding，NetTcpBinding以及NetNamedPipeBinding 綁定，因此必然會影響服務(wù)實(shí)例的激活類型，最主要的是對Session模式的影響。首先BasicHttpBinding并不支持Session模式的激 活類型。NetTcpBinding以及NetNamedPipeBinding綁定雖然支持Session模式，但是由于Stream操作不支持可靠消 息傳遞，即不能將ReliableSession設(shè)置為true。因此在定義服務(wù)契約的SessionMode時，不能將其值設(shè)置為 SessionMode.Required，否則會拋出異常。

實(shí)際上，Stream操作（指TransferMode不為 Buffered）本身并不支持Session模式。即使我們在使用NetTcpBinding時，將服務(wù)契約的SessionMode設(shè)置為 Allowed，并將服務(wù)的InstanceContextMode設(shè)置為PerSession，服務(wù)的執(zhí)行方式仍然是PerCall方式。（如果不是 Stream操作，這樣的設(shè)置服務(wù)應(yīng)為PerSession模式）

因此，在執(zhí)行Stream操作時，即使按照Session模式對服務(wù)進(jìn)行設(shè)置，如果我們通過OperationContext.Current.SessionId去獲得會話ID，其值應(yīng)該為空。

此外，由于傳輸?shù)腟tream對象較大，可能會消耗過長的時間，因而建議增大綁定的SendTimeout屬性值。例如設(shè)置為10分鐘。編程方式設(shè)置為：

binding.SendTimeout?=?TimeSpan.FromMinutes(10);

配置文件的設(shè)置方式為：

<binding?……?sendTimeout="00:10:00"/>

注意，對綁定的相關(guān)設(shè)置必須要求服務(wù)端與客戶端的配置一致。最佳實(shí)踐是均通過配置文件進(jìn)行設(shè)置。例如在我的應(yīng)用程序中是這樣設(shè)置的：

<basicHttpBinding>
????????<binding?name="DocumentExplorerServiceBinding"?
???????????????? sendTimeout="00:10:00"?
???????????????? transferMode="Streamed"
???????????????? messageEncoding="Text"?
???????????????? textEncoding="utf-8"?
???????????????? maxReceivedMessageSize="9223372036854775807">??????????
????????</binding>
</basicHttpBinding>





本文轉(zhuǎn)自wayfarer51CTO博客，原文鏈接：http://blog.51cto.com/wayfarer/280105，如需轉(zhuǎn)載請自行聯(lián)系原作者 與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的WCF中的Stream操作的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。