.Net流：返回与提供

Question

我一直想知道在C＃.Net中使用Stream类的最佳做法是什么。提供已写入或提供的流是否更好？ 即：

public Stream DoStuff(...)
{
    var retStream = new MemoryStream();
    //Write to retStream
    return retStream;
}

而不是;

public void DoStuff(Stream myStream, ...)
{
    //write to myStream directly
}

为了生命周期控制，我总是使用前面的例子，但我觉得这是一种糟糕的流式传输方式＆＃34;由于缺少更好的词，Stream为{。}。

Answer 1

我更喜欢“第二种方式”（在提供的流上运行），因为它有一些明显的优势：

• 您可以拥有多态性（假设您的签名证明您可以对提供的{em>任何类型的Stream进行操作。）
• 现在或以后很容易将其抽象为Stream扩展方法。
• 你明确划分责任。此方法不应该关注如何构造流，而只关心如何对其应用某个操作。

另外，如果你要返回一个新的流（选项1），你会感到有点奇怪，你必须先再次Seek才能从中读取它（除非你那样做）在方法本身中，由于可能并不总是需要，因此再次是次优的 - 在所有情况下都可能无法从之后读取流。在将现有流传递给明确写入流的方法之后，必须Seek似乎并不那么尴尬。

Answer 2

我看到Streams的好处是你不需要知道你要传输的是什么。

在第二个示例中，您的代码可能是写入内存，可能是直接写入文件或某些网络缓冲区。从函数的角度来看，实际的输出目的地可以由调用者决定。

出于这个原因，我更喜欢第二种选择。

第一个功能就是写入内存。在我看来，如果它不返回流，而是实际的内存缓冲区会更清楚。然后，如果他/她愿意，呼叫者可以附加记忆流。

public byte[] DoStuff(...)
{
    var retStream = new MemoryStream();
    //Write to retStream
    return retStream.ToArray();
}

Answer 3

第二个100％。您不想假设他们想要哪种流。他们想流式传输到网络还是磁盘？他们是否希望将其缓冲？把这些留给他们。

他们可能还想重用流，以避免一遍又一遍地创建新的缓冲区。或者他们可能想在同一流上端对端流式传输多个事物。

如果提供流，则可以控制流的类型及其生存期。否则，您也可能只返回类似字符串或数组的内容。流实际上并没有给您带来任何好处。