我知道该模型涉及在后台运行的计划任务，该任务运行通过 Web 请求注册的作业，但是对于将所有内容保留在 ASP.net 中的想法怎么样？
-
用户上传 CSV 文件也许有几千行。这些行被持久保存到数据库中。我认为这可能需要一分钟左右，这是可以接受的等待时间。
-
请求返回到浏览器，然后自动 Ajax 请求将返回到服务器并请求（例如，一次十行）并处理它们。 （每一行都需要多个 Web 服务请求。）
-
Ajax 调用返回，显示更新，然后另一个自动 Ajax 请求返回以获取更多行。重复此过程，直到完成所有行。
-
如果用户离开网页，则他们可以返回并重新启动作业。
有什么想法吗？
干杯，伊恩。
I'm aware of the model that involves a scheduled task runninng in the back ground which runs jobs registered with a web request but how about this for an idea that keeps everything within ASP.net...
-
User uploads a CSV file with, perhaps, several thousand rows. The rows are persisted to the database. I think this would take maybe a minute or so which would be an acceptable wait.
-
Request returns to the browser and then an automatic Ajax request would go back to the server and request, say, ten rows at a time and process them. (Each row requires a number of web service requests.)
-
Ajax call returns, display is updated and then another automatic Ajax request goes back for more rows. This repeats until all rows are completed.
-
If user leaves the web page, then they could return and restart the job.
Any thoughts?
Cheers, Ian.
发布评论
评论（3）
如果我没说错的话，您实际上不需要后台作业和长时间运行的请求之间的任何“交互”，您只想通过传入请求“启动”后台作业？这可不是什么好主意。看一下 Quartz.NET 项目，它是可嵌入到 ASP.NET 应用程序中的调度程序，它将为您处理这些事情，而不需要请求。当然，如果应用程序池关闭，您的调度程序也会关闭，但即使使用长时间运行的请求解决方案，也不能保证这种情况不会发生，这取决于浏览器在另一端等待。
另请参阅 phil haack 关于此主题的这篇有趣文章，其中包含他自己的专门针对 ASP.NET 的小调度程序库：
http://haacked.com/archive/2011/10/16/the-dangers-of-implementing-recurring-background-tasks-in-asp-net.aspx
If i get you right, you actually dont need any "interaction" between background jobs and the long-running request, you just want to "lauch" background jobs with incoming requests? Not such a good idea. Take a look at the Quartz.NET project, it is scheduler embeddable into ASP.NET application, it will handle this stuff for you without need of requests. Of course, if there is app pool shutdown, also your scheduler goes down, but this you cant guarantee not to happen even with your long-running requests solution, dependent on browser waiting on other side.
Also take a look on this interesting article from phil haack on this topic, with his own little scheduler library specific for ASP.NET :
http://haacked.com/archive/2011/10/16/the-dangers-of-implementing-recurring-background-tasks-in-asp-net.aspx
服务器端程序（或理想的服务）仍然可以是快速和脏的，并且会更可靠。您仍然可以按照您的建议执行步骤 1，上传文件并插入数据（不要忘记增加 web.config 中的 maxRequestLength 超时值）。然后在服务器上运行一个程序来检查新记录并处理它们。
如果用户需要状态，您可以在数据库中为每个文件存储一个条目，并在导入完成后更新数据库记录。
A server side program (or ideally service) could still be quick and dirty and would be more reliable. You could still do step 1 as you have proposed, upload the file and insert the data ( don't forget to increase the maxRequestLength time out value in the web.config ). Then have a program running on the server that checks for new records and processes them.
If the user needs status you could store an entry in the database for each file and update the database record when the import is complete.
也许我正在阅读问题并以一种奇怪的方式解释它，但是为什么您不能将文件读入数据库并将您已完成的文件的当前行存储在表中。然后，您可以通过数据库跟踪您的进度，并仅发送小的 json 对象，告诉用户您已经走了多远。这样，如果他们的连接断开，您可以继续处理他们的请求，如果他们稍后返回，您可以通知他们工作进度。此外，如果多个客户端正在连接，您可以使用数据库来排队和限制（通过序列化）工作负载。或者，如果用户在作业中连接另一个文件，那么他们的新请求将在当前作业之后排队。
Maybe I'm reading the question and interpreting it in a weird way, but why couldn't you read the file into a database and store in a table the current line of the file that you've completed through. You could then track your progress via the db and just send small json objects telling the user how far along you are. That way if their connection drops you can keep processing their request, and if they return later you can notify them of how far along the job is. Also, if multiple clients are connecting you can use the db to queue and throttle (by serializing) the workload. Or if the user connects mid-job with another file, then their new request will be queued up after their current job.