Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
How to create fire and forget tasks Q&A in ASP.NET Core with dependency injection support?
One of the legacy applications our team manages contained the following pattern (in the controller):
// initialization
private readonly IServiceScopeFactory _serviceScopeFactory;
public FooController(IServiceScopeFactory serviceScopeFactory)
{
_serviceScopeFactory = serviceScopeFactory;
}
// IServiceScopeFactory was polluting the application services
public IActionResult Foo()
{
Task.Run(() => _fooService.DoFoo(_serviceScopeFactory));
return Ok();
}
The main purpose was to allow for fire-and-forget tasks because some of them could be quite long and the client should not wait for them to complete.
I guess that this was required to still benefit from DI since all application logic relies on it.
I have found this SO question dealing and this answer seems to do the trick, but votes = 0 suggests that was not found particularly useful (despite the 10K views).
Is there a quick way to allow for fire-and-forget tasks with DI support?
1 answer
The following users marked this post as Works for me:
| User | Comment | Date |
|---|---|---|
| Peter Taylor |
Thread: Works for me HangFire is what I was going to propose as soon as I saw the question |
Jan 11, 2022 at 08:43 |
The way I made this work is not very quick but might provide extra benefit in the future. I have added Hangfire support to the application and use its BackgroundJob enqueuing mechanism as follows:
Plugging Hangfire
using Hangfire;
using Hangfire.MemoryStorage;
public void ConfigureServices(IServiceCollection services)
{
// other initialization here
ConfigureHangfire(services);
}
private void ConfigureHangfire(IServiceCollection services)
{
// this can be replaced with another type of storage
// for actual persistence, but it is enough for this example
services.AddHangfire(opt => opt.UseMemoryStorage());
JobStorage.Current = new MemoryStorage();
}
}
public void Configure(IApplicationBuilder app)
{
// other configuration here
StartHangFireJobs(app);
}
protected void StartHangFireJobs(IApplicationBuilder app)
{
app.UseHangfireServer();
// this is optional, but it provides a nice dashboard to see all job runs
app.UseHangfireDashboard();
}
Actual usage
public IActionResult ExportPTBContracts()
{
// virtually anything can be called here
// and the DI will work as expected
BackgroundJob.Enqueue(() => _fooService.DoFoo());
return Ok();
}
The main disadvantage is that a third-party library is used. However, it allows to easily check how the jobs actually ran (how frequent were called, how much it took, unhandled errors, etc).
More information is provided by Hangfire Docs.
0 comment threads