首先,我喜欢 ASP.NET MVC.这个问题不是批评它.相反,我想确认我认为我看到了什么,并确保我没有错过任何东西.忍受我......如果没有提供一点上下文,我无法回答这个问题.
问题与在Stream中返回数据以响应HTTP Post有关.在ASP.NET MVC之前的旧时代,您可以通过将数据直接传递到Response流来实现此目的.例如,您可能会执行以下操作:
someObjectThatDumpsOutputToWhateverStreamYouHandIt.WriteTo(Response.OutputStream);
请注意此代码的一个关键方面:我没有实现任何后备存储.我没有必要将信息流传输到字节数组,或将其转储到临时文件中.相反,ASP.NET已经设置了一个Stream,用于将响应传回浏览器,我已将我想要的输出直接转储到该Stream中.这在CPU,内存和执行时间方面比将所有数据复制到某个临时位置然后将其移动到Response流中更有效.
但是,它对单元测试不是很友好.实际上,您仍然可以在ASP.NET MVC中执行此类代码,但自定义将避免这种情况.相反,ASP.NET MVC会鼓励您返回ActionResult.ActionResult是一个ASP.NET MVC概念,主要用于单元测试友好.它允许您"声明"您想要做的事情.单元测试可以执行Controller操作并确认它获得了预期的ActionResult.该单元测试可以在浏览器外部运行.
ASP.NET MVC提供了一种用于返回数据流的ActionResult.它被称为FileStreamResult.不要让名字中的"文件"这个词欺骗你.它是关于返回数据流,正如我们上面所讨论的那样.
但是,这是问题所在,也是我的问题的基础:如果你让你的Controller方法返回一个FileStreamResult,然后你把它想要返回一个Stream,那么它似乎没有任何方法可以转储数据直接到Response流.现在,您似乎被迫使用后备存储(例如内存或文件)创建自己的Stream,将数据转储到其中,然后将该Stream传递给您返回的FileStreamResult.
所以看来我必须做这样的事情(故意省略dispose/using /等):
MemoryStream myIntermediateStream = new MemoryStream();
someObjectThatDumpsOutputToWhateverStreamYouHandIt.WriteTo(myIntermediateStream );
return new FileStreamResult(myIntermediateStream, "application/pdf");
请注意,myIntermediateStream会将大数据流的内容临时存储在内存中,以便FileStreamResult稍后可以将其再次复制到Response输出流中.
所以这是我的问题:我是否忽略了某些内容,或者说使用FileStreamResult强制您拥有一个中间存储位置是否准确,如果您直接写入Response的输出流,您将不会被迫拥有这个位置？
谢谢.