c＃流中的方向選擇

Question

c＃中的一些流似乎有一個「方向」，因爲它們意味着在一個方向上使用。對於其中的一些，如FileStream和NetworkStream是有道理的，但其他的則沒有。

例如與GZipStream您可以壓縮或通過將其寫入到視構造參數的流解壓縮數據。另一方面，CryptoStream強制加密數據到遠端，解密被強制進行讀操作，加密是寫操作。

特別是隨着加密實現工作時它一直煩人被強制在特定方向推壓的數據。

是否有任何具體的設計動機只在一個方向上實現某些流？

更新：爲了澄清，我在尋找的是爲什麼一些設計只使用一個方向，而不是方向的選擇是理解。有沒有人想過這個，並找到了解釋，或者沒有。

接收需要儘快處理的正在運行的數據流。因此，您希望在收到解碼流時將字節寫入解碼流。

隨着CryptoStream的自然就沒有關係你把MemoryStream的多少字節，你可以有多少字節讀取解密。在這裏，您必須考慮具體實施細節，如塊大小。

GZipStream可以通過改變壓縮的方向來解決這個問題。

Answer 1

解密被迫讀操作和加密是一個寫操作

是否有實現只在一個方向上的一些流的任何具體的設計動機是什麼？

好吧，假設它是倒過來。在寫入文件時解密，這聽起來是明智的，但數據仍然必須來自某個地方。

這意味着你將需要一個Stream.CopyTo()和偶爾的MemoryStream。這些也是您現在可以使用的工具。

這個選擇可能稍微有點武斷，但是你需要選擇一個方向，而在寫入時加密似乎對我來說是最自然的。

Answer 2

如果您認爲CryptoStream的作爲加密內容的容器中，可以很明顯看出某事。你想Read（）出來應該是解密和某事。你寫入（）到它應該被加密。