通过依赖注入实现后台任务的DbContext

Question

我可能没有按照正确的方向思考。我对依赖注入和ASP.Net核心还是个新手。

我有一个ASP.Net核心网站，其中一个任务是导入数据从excel工作表到一个数据库，用户将上传。excel表格可能很大，数据转换任务也很耗时，因此我希望在后台执行它们。即用户将上传工作表，响应将立即发送，后台作业/线程将导入数据。

我正在尝试通过以下方式运行后台作业：

Task.Run(() => ProcessImport(model));

我遇到的问题是，流程导入方法调用服务，这些服务具有通过作为作用域添加的ASP.Net依赖项注入容器访问AppDbContext的存储库类，一旦响应被发回，上下文就会被处理掉。我得到了一个运行时异常，你不能使用一个上下文后，它被释放。

我的问题是，处理这种情况的最佳方法是什么？我应该让AppDbContext成为单例吗？我应该在ProcessImport方法中创建一个新的AppDbContext实例，然后传递它吗？我读到过DbContext不是线程安全的，所以这是一个好方法吗？

Answer 1

您应该将IServiceScopeFactory实例(它是单例)传递到您的任务中。

在任务内部，当数据到达时，您应该创建新的CreateScope()并从该作用域请求服务。当数据处理完成时-释放此作用域(但为下一次运行保留对IServiceScopeFactory的引用)。

请参见this示例。我使用这个库运行小而快速的任务。

对于繁重/长时间运行的任务，正如Gert所写的，不要依赖于您的任务总是运行到完成。准备好重新启动，准备好重新处理相同的数据。

Answer 2

要分解问题，请执行以下操作：

1. 处理这种情况的最佳方法是什么？

API处理长时间运行的任务并不理想。你可以把这个过程委托给一个后台application

• Should，让它成为AppDbContext单例？

在web应用程序场景中，dbContext不应该是单例的，因为它会带来问题，比如管理transactions.

• what是处理这种情况的最好方法？

对各种services/process:进行细分

- The API that will take a file. Ideally the API should just take the file as input and persist it to disk or to database.
- A service that will process the file. Create this component/service as a separate library. Then consume this library from a console app. This way you can profile the performance. Make it fire and forget  method by making it async method. This way you have flexibility of reusing your code.
- If you don't expect a lot of file uploads, you can reuse the library at your API controller and execute the method using QueueBackgroundWorkItem.  See here for reference: [http://www.hanselman.com/blog/HowToRunBackgroundTasksInASPNET.aspx](http://www.hanselman.com/blog/HowToRunBackgroundTasksInASPNET.aspx) 

​

1. 我是否应该在ProcessImport方法中创建一个新的AppDbContext实例，并传递它？

因为它不是线程安全的，所以在每个线程中创建并使用dbContext类的单独实例。

• 我读到DbContext不是线程安全的，所以这是一个好方法吗？

有关使用EF dbContext的深入指南，请查看此博客：http://mehdi.me/ambient-dbcontext-in-ef6/