我正在使用mvc3，虽然我经常看到这个问题，但我还没有找到关于使用哪种技术的明确答案。大多数解决方案似乎互相矛盾，使用新旧库混合。似乎有很多关于异步的讨论，但后来出现了许多答案，说明为什么它不安全。
需要的是。
MVC3网站 - 用户点击按钮创建报告。
报告很大，将创建并存储在Web服务器磁盘上 （最多可能需要10分钟）。
用户无需知道报告何时完成创建。
网页只返回正在创建报告的事实并允许您 继续不再与该过程互动。
为了争论，服务器硬件相当不错，但可能超过100 并发用户，他们都在同一时间创建自己独立的大型报表。 我想它可以创造的唯一问题是服务器硬件功能强大 足够而不是配置或软件问题。
我一直在关注'任务并行库'，这可能是实现这一目标的方法。但我再次得到许多关于如何做到这一点的不同报道。
有些人建议使用WCF服务但是有很多相互矛盾的报告，说明为什么/为什么不这样做。即现在过时/更好的替代品等
一般来说，我想要的是在另一个不会弄乱iis的线程中创建文件（从池中运行线程等等取决于使用的方法）
答案 0 :(得分：0)
这是一套非常开放的问题。这不是一件坏事，但对他们来说没有太多“正确”的直接答案。但有一些事情需要注意。一些选择取决于您的可靠性要求等。
例如，你想要一个不会“弄乱iis”的方法，指的是让正在服务请求的线程池挨饿。为此，您需要在线程池之外的线程上进行工作。您可以以您认为合适的任何方式执行此操作，具体取决于您的要求和测量的性能特征。您有两个选择：
还有第三种方法可以在您选择的框架中使用异步支持。对于MVC，您有异步控制器。我不会将此列为您的选项，因为您说在发送响应之前您不想等待报告完成。异步控制器/页面在这里不会给你买任何东西，实际上会受到伤害。
你还必须考虑另一方面的可靠性：是的，你不想搞砸iis，但你也关心iis弄乱你吗？您的网络流程可以回收，或者由于任何其他原因导致网络流程中断，您的报告生成也将会消失。如果这对您很重要，那么您必须有一个恢复机制或主机不在进程中，因此您可以单独控制服务的可靠性。
托管进程外的另一个好处是，您可以在与前端应用程序不同的服务器上物理部署该进程。然后，您可以优化以使用该应用程序中的线程池，而无需与前端有任何关系。如果你有很多事情要做，它也会减少上下文切换。此外，如果需要，您可以单独扩展报告生成过程。最后，你可以单独处理自动化excel等权限和其他问题，如果这是你要走的路径。
进程外的缺点是增加了复杂性。您需要在两者之间进行一些通信，可能是WCF单向呼叫，也许是消息总线，无论哪种方式都符合您的要求。您需要根据需求和可靠性/可扩展性等所期望的价值来衡量这一成本。
现在，对于您进行异步工作的首选工具，这在很大程度上取决于您。在我看来，TPL是异步工作的一个非常好的抽象，并且用于运行任务的默认任务调度程序对于线程使用非常聪明，因此您在很大程度上不必考虑它。此外，.NET 4.5带有内置的编译器支持，使得使用TPL比现在更简单，看起来更像是同步样式（搜索async / await或者可能以here为例。 ）
最重要的是，我不会过于紧张或瘫痪一般使用哪种技术堆栈。列出您的非功能性需求 - 性能，可扩展性，可靠性等 - 确定哪些组合符合您的要求，并选择一个。如果您担心做出错误的选择，请尝试以允许您有效处理此区域变更的方式构建解决方案。如果需要，您可以随时测量和更改。