What is an correct way to inject db context to Hangfire Recurring job?

Question

I'm using HangFire to send emails to users in the background, regularly.

I'm obtaining email addresses from database, but I'm not sure whether I'm "injecting" database context to service that's responsible for sending emails correctly

This works correctly, is there a better way to do it?

public void Configure(IApplicationBuilder app, IHostingEnvironment env, Context context)
{
    (...)

    app.UseHangfireDashboard();
    app.UseHangfireServer(new BackgroundJobServerOptions
    {
        HeartbeatInterval = new System.TimeSpan(0, 0, 5),
        ServerCheckInterval = new System.TimeSpan(0, 0, 5),
        SchedulePollingInterval = new System.TimeSpan(0, 0, 5)
    });

    RecurringJob.AddOrUpdate(() => new MessageService(context).Send(), Cron.Daily);

    (...)
    app.UseMvc();
}

public class MessageService
{
    private Context ctx;

    public MessageService(Context c)
    {
        ctx = c;
    }

    public void Send()
    {
        var emails = ctx.Users.Select(x => x.Email).ToList();

        foreach (var email in emails)
        {
            sendEmail(email, "sample body");
        }
    }
}

[Hangfire Docs: Using IoC containers](http://docs.hangfire.io/en/latest/background-methods/using-ioc-containers.html) — Trenton McKinney, Oct 05 '19 at 04:45

score 18 · Accepted Answer · answered Oct 05 '19 at 04:23

I just looked to the similar question and did not find the information in one place, so posting my solution here.

Assume you have your Context configured as a service, i.e.

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
    ....
    services.AddDbContext<Context>(options => { ... });
    ....
}

This makes the IServiceProvider capable to resolve the Context dependency.

Next, we need to update the MessageService class in order to not hold the Context forever but instantiate it only to perform the task.

public class MessageService
{
    IServiceProvider _serviceProvider;
    public MessageService(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public void Send()
    {
        using (IServiceScope scope = _serviceProvider.CreateScope())
        using (Context ctx = scope.ServiceProvider.GetRequiredService<Context>())
        {
            var emails = ctx.Users.Select(x => x.Email).ToList();

            foreach (var email in emails)
            {
                sendEmail(email, "sample body");
            }
        }
    }
}

And finally we ask Hangfire to instantiate the MessageService for us, it will also kindly resolve the IServiceProvider dependency for us:

RecurringJob.AddOrUpdate<MessageService>(x => x.Send(), Cron.Daily);

No, no, no, NNNOOOOOO. Please don't inject the `IServiceProvider`. Change ctor to be `public MessageService(Context context)` and use the given object in your `.Send()` method. Providing the `IServiceProvider` is the service-locator anti-pattern. — Oliver, Jul 27 '23 at 07:01

score 1 · Answer 2 · answered Dec 02 '18 at 04:52

Definitely need to use DI (StructureMap or etc) for your issue. Please refactor your config file and decouple the "Context" class dependency from config class. Also introduce a container class to map DI classes (auto or manual).

Create Container class

Add container to Hangfire:

GlobalConfiguration.Configuration.UseStructureMapActivator(Bootstrapper.Bootstrap());

Also change job registration in config class:

RecurringJob.AddOrUpdate<MessageService>(x => x.Send(), Cron.Daily);

score 1 · Answer 3 · answered Jul 27 '23 at 06:41

When you access IServiceProvider directly, you circumvent the natural scoping mechanism provided by the ASP.NET dependency injection container, leading to potential issues with the lifetime and management of your service instances.

Using IServiceProvider directly in a controller may result in unintended behavior and problems like:

Scope-related bugs: Resolving a scoped or singleton service in a transient controller can lead to unexpected shared state between requests, causing data corruption or concurrency issues.

Resource Leaks: Manually managing the lifetime of services obtained through IServiceProvider can result in improper disposal, leading to resource leaks and degraded application performance.

Inconsistent Scoping: Different parts of your application might expect different service lifetimes. Using IServiceProvider directly in multiple places can make it challenging to maintain a consistent scope for a service throughout the application.

While creating your own scope, as suggested in the top-rated answer, might technically work, it's considered a code smell and unnecessary.

What is an correct way to inject db context to Hangfire Recurring job?

3 Answers3