First of all, I *love* ASP.NET MVC. This question is not a criticism of it. Rather, I want to confirm what I think I see and make sure I haven't missed something. Bear with me ... I can't get to the question without providing a little bit of context.

The question has to do with returning data in a Stream in response to an HTTP Post. In the olden days before ASP.NET MVC, you could do this by piping your data directly into the Response stream. For example, you might do something like this: 

```
someObjectThatDumpsOutputToWhateverStreamYouHandIt.WriteTo(Response.OutputStream); 

```

Notice a key aspect of this code: I have not implemented *ANY* backing store. I did not have to stream the info to a byte array, or dump it into a temporary file. Rather, ASP.NET had already set up a Stream for the purpose of communicating the response back to the browser, and I have dumped the output I want directly into that Stream. This is more efficient in terms of CPU, memory, and execution time than copying all the data to some temporary location and then moving it into the Response stream.

However, it is not very friendly to unit tests. In fact, you can still do that kind of code in ASP.NET MVC, but the custom would be to avoid that. Rather, ASP.NET MVC would encourage you to return an ActionResult. The ActionResult is an ASP.NET MVC concept that exists mostly to be unit test friendly. It allows you to "declare" what you want done. A unit test can exercise a Controller action and confirm that it gets the expected ActionResult. That unit test can run outside a browser.

ASP.NET MVC offers a kind of ActionResult for returning Streams of data. It is called FileStreamResult. Don't let the word "File" in the name fool you. It is about returning a Stream of data, exactly as we are talking about above.

However, here's the problem, and the basis of my question: **If you make your Controller method return a FileStreamResult, and you hand it a Stream that you want to return, then it appears there is no longer any way for you to dump the data directly to the Response stream.** Now, it appears you are forced to make your own Stream with a backing store (such as memory or a file), dump your data into it, and then hand that Stream to the FileStreamResult that you return.

So it appears I have to do something like this (intentionally omitting dispose / using / etc.):

```
MemoryStream myIntermediateStream = new MemoryStream();
someObjectThatDumpsOutputToWhateverStreamYouHandIt.WriteTo(myIntermediateStream ); 

return new FileStreamResult(myIntermediateStream, "application/pdf");

```

Notice that myIntermediateStream causes the contents of the large stream of data to be stored in memory temporarily, so that the FileStreamResult can later on copy it again into the Response output stream.

**So here's my question: Have I overlooked something, or is it accurate to say that using FileStreamResult forces you to have an intermediate storage location that you would not be forced to have if you were to write directly to the Response's output stream?**

Thanks.