.Net 流：返回与提供答案

【问题标题】：.Net streams: Returning vs Providing.Net 流：返回与提供
【发布时间】：2015-05-25 20:15:23
【问题描述】：

我一直想知道在 C# .Net 中使用 Stream 类的最佳实践是什么。提供一个已写入的流还是提供一个流更好？即：

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

相对于；

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

为了生命周期控制，我一直使用前一个示例，但我感觉这是一种糟糕的“流式传输”方式，因为没有更好的词。

【问题讨论】：

【解决方案1】：

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

另外，如果您要返回一个新流（选项 1），您必须先再次 Seek 才能从中读取，这会让人感觉有点奇怪（除非您在方法本身，这又是次优的，因为它可能并不总是需要 - 在所有情况下都可能不会从之后读取流）。在将已经存在的流传递给明确写入流的方法之后必须 Seek 似乎并不那么尴尬。

【讨论】：

假设，我想执行一个流式操作，它是一个更大的回报结构的一部分？例如：IResponseObject DoThingWithStream(//args) 这会影响方法吗？

【解决方案2】：

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

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

因此，我更喜欢第二种选择。

第一个函数只是写入内存。在我看来，如果它不返回流，而是返回实际的内存缓冲区，那会更清楚。然后，调用者可以根据需要附加一个内存流。

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

【讨论】：

【解决方案3】：

100% 第二个。你不想假设他们想要什么样的流。他们想要流式传输到网络还是磁盘？他们希望它被缓冲吗？把这些留给他们。

他们可能还想重用流以避免一遍又一遍地创建新缓冲区。或者他们可能希望在同一个流上端到端地流式传输多个内容。

如果他们提供流，他们可以控制它的类型以及它的生命周期。否则，您还不如只返回字符串或数组之类的东西。直播并没有真正为您带来任何好处。

【讨论】：