我的团队正在开发一个ASP。NET应用程序，其中包括一个导入功能。导入通常由用户在网页中输入一些设置启动，包括要导入的本地文件。当用户点击"导入"时，需要先上传文件，然后再导入。
导入可能是一个相当长的操作，所以不可能直接从aspx.cs代码中完成，它需要在一些后台方式完成。同样重要的是，一旦文件上传，导入不会丢失。我还希望导入能够立即启动，而不必等待每隔X分钟检查可用工作的服务或计划任务。
到目前为止，我找到的替代方案是:
- 后台线程从线程池或类似的ASP.NET。将大部分工作，但如果应用程序池被回收，工作将丢失。
- 带有定时的服务，定时检查DB中的工作表并运行导入。将工作，但要么有延迟，要么导致非常频繁的DB工作请求。
- 带有更改通知查询的服务(不知道确切的名称，但可以从SQL server订阅更改)
- 服务通过MSMQ获取工作项。
- WCF服务，托管在系统服务中，而不是在ASP中。NET以避免回收。要么从ASP内部调用WCF服务;. NET或者直接公开并通过AJAX从客户端调用(如果非iis托管的WCF可以公开AJAX端点)。
还有其他选择吗?是否有人有上述替代方案的经验?
你可以有一个windows服务，它监视上传目录的变化(例如使用FileSystemWatcher)。
这样，在服务开始工作之前将没有(或只有最小的)延迟，并且您不需要来自服务的任何类型的轮询。
至于设置(由用户输入):要么将它们存储在DB中(并从服务中查询它们)，要么也将它们写入文件
正如您所提到的，有不同的方法和选择。
我们已经成功地使用了一个Windows服务作为代理(作业管理器)，并创建了Worker类，这些类被插入并配置了一个小的ASPX页面，当添加一个新的Worker时，根本不需要触摸代理。
通过这种方式，代理始终作为windows服务运行，并根据worker的类型及其配置调用worker的execute方法并执行作业。
你也可以有一个更简单的设计，就像你说的MSMQ，我们也使用和工作良好
这类似于我们根据用户的要求发送报告。
- 用户通过Web应用程序请求报告，该应用程序将记录添加到Queue表中。
- Windows Service监视队列表并生成pdf格式的报告(根据报告类型，可能需要几秒钟到一个多小时)。 另一个Windows服务通过电子邮件发送报告，一旦他们准备好。
#2和#3都定期检查DB(每个检查队列项的相关"状态")，并将所有排队但未处理的项作为批处理处理-一次不是一个。
调用执行实际工作的CLR存储过程的DB触发器?
虽然我对MSMQ有很好的经验，但不要用太多的数据使MSMQ过载。Post import-id:s或类似于MSMQ，并将实际负载存储在数据库表中。MSMQ可以处理相当多的数据，但大多数管理工具变得非常慢，因为它们倾向于在启动时偷看队列中的所有消息(包括有效负载)。