如何封装Hangfire取消令牌？基于.NET Core清洁架构的技术问询

Great question—keeping your ApplicationCore decoupled from implementation details like Hangfire is exactly what clean architecture is all about, so you’re already heading in the right direction. Let’s look at two optimized approaches to simplify your current setup while maintaining that crucial separation of concerns.

Option 1: Use .NET's Native CancellationToken (Simplest Approach) #

Instead of defining a custom IJobCancellationToken interface, leverage the built-in CancellationToken from System.Threading—this is a framework type, so your ApplicationCore can use it without any Hangfire dependencies. The trick is to map Hangfire's JobCancellationToken to CancellationToken in your Infrastructure layer.

Step 1: Update Your ApplicationCore Task Method #

Modify your task to accept a standard CancellationToken:

public async Task GenerateSubmission(Guid SetupGuidId, CancellationToken cancellationToken) 
{ 
    try 
    { 
        var setup = await this.SetupRepository.GetByGuidIdAsync(SetupGuidId); 
        var forecast = await this.GetCurrentForecastForSetup(setup, DateTime.UtcNow, cancellationToken); 
        // Rest of your logic
    } 
    catch (Exception e) 
    { 
        Console.WriteLine(e); 
        throw; 
    } 
}

Step 2: Update Your IBackgroundJobClient Interface #

Adjust the interface to accept expressions that take a CancellationToken:

namespace ApplicationCore.Interfaces 
{ 
    using System; 
    using System.Linq.Expressions; 
    using System.Threading;
    using System.Threading.Tasks; 
    public interface IBackgroundJobClient 
    { 
        void AddOrUpdate<T>( 
            string recurringJobId, 
            Expression<Func<T, CancellationToken, Task>> methodCall, 
            string cronExpression); 
        void RemoveIfExists(string recurringJobId); 
    } 
}

Step 3: Implement the Mapping in Infrastructure #

In your Hangfire implementation, convert the CancellationToken-accepting expression to one that uses Hangfire's JobCancellationToken, extracting its ShutdownToken property:

namespace Infrastructure.BackgroundJobs 
{ 
    using System; 
    using System.Linq.Expressions; 
    using System.Threading;
    using System.Threading.Tasks; 
    using Hangfire; 
    using ApplicationCore.Interfaces;

    public class HangfireBackgroundJobClient : IBackgroundJobClient 
    { 
        public void AddOrUpdate<T>( 
            string recurringJobId, 
            Expression<Func<T, CancellationToken, Task>> methodCall, 
            string cronExpression) 
        { 
            // Convert the expression to accept Hangfire's JobCancellationToken
            var hangfireTokenParam = Expression.Parameter(typeof(JobCancellationToken), "hangfireToken");
            var convertedCall = Expression.Invoke(
                methodCall,
                methodCall.Parameters[0],
                Expression.Property(hangfireTokenParam, nameof(JobCancellationToken.ShutdownToken))
            );

            var convertedExpression = Expression.Lambda<Func<T, JobCancellationToken, Task>>(
                convertedCall,
                methodCall.Parameters[0],
                hangfireTokenParam
            );

            RecurringJob.AddOrUpdate<T>(recurringJobId, convertedExpression, cronExpression); 
        } 

        public void RemoveIfExists(string recurringJobId) 
        { 
            RecurringJob.RemoveIfExists(recurringJobId); 
        } 
    }
}

Step 4: Schedule the Job as Usual #

When scheduling, you don’t need to pass a token—Hangfire will automatically inject its JobCancellationToken, which our mapping converts to the standard CancellationToken your core logic expects:

public async Task<Setup> EnableSetup(Setup setup) 
{ 
    setup.Enable(); 
    this.jobClient.AddOrUpdate<IForecastService>( 
        setup.GuidId.ToString(), 
        f => f.GenerateSubmission(setup.GuidId, default), // Default is a placeholder; Hangfire replaces it
        "45 */2 * * *"); 
    await this.setupRepository.UpdateAsync(setup); 
    return setup; 
}

This approach is lightweight, uses standard .NET types, and keeps your ApplicationCore completely free of Hangfire references.

Option 2: Simplified Token Adapter (For Custom Token Logic) #

If you ever need to add custom cancellation logic beyond what CancellationToken provides, you can keep your IJobCancellationToken interface but simplify the adapter to wrap Hangfire's token instead of inheriting from it:

Step 1: Keep Your ApplicationCore IJobCancellationToken #

namespace ApplicationCore.Interfaces 
{ 
    using System.Threading; 
    public interface IJobCancellationToken 
    { 
        CancellationToken ShutdownToken { get; } 
        void ThrowIfCancellationRequested(); 
    } 
}

Step 2: Create a Lightweight Adapter in Infrastructure #

namespace Infrastructure.BackgroundJobs 
{ 
    using Hangfire;
    using ApplicationCore.Interfaces;
    using System.Threading;

    public class HangfireJobCancellationTokenAdapter : IJobCancellationToken
    {
        private readonly JobCancellationToken _hangfireToken;

        public HangfireJobCancellationTokenAdapter(JobCancellationToken hangfireToken)
        {
            _hangfireToken = hangfireToken;
        }

        public CancellationToken ShutdownToken => _hangfireToken.ShutdownToken;

        public void ThrowIfCancellationRequested()
        {
            _hangfireToken.ThrowIfCancellationRequested();
        }
    }
}

Step 3: Configure Hangfire to Use the Adapter #

Use a custom JobActivator to replace Hangfire's JobCancellationToken with your adapter when resolving job arguments:

public class HangfireJobActivator : JobActivator
{
    private readonly IServiceProvider _serviceProvider;

    public HangfireJobActivator(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public override object ActivateJob(Type jobType)
    {
        return _serviceProvider.GetService(jobType);
    }

    public override object ActivateJob(Type jobType, IEnumerable<object> arguments)
    {
        // Replace Hangfire's token with our adapter
        var adaptedArgs = arguments.Select(arg => 
            arg is JobCancellationToken hangfireToken 
                ? new HangfireJobCancellationTokenAdapter(hangfireToken) 
                : arg).ToList();
        
        return base.ActivateJob(jobType, adaptedArgs);
    }
}

Register it in your Startup:

services.AddHangfire(config =>
{
    // Your existing Hangfire configuration (storage, etc.)
    config.UseActivator(new HangfireJobActivator(services.BuildServiceProvider()));
});

This keeps your core logic decoupled while allowing you to extend cancellation behavior if needed.

Final Recommendation #

Option 1 is the best default choice—it’s simpler, uses standard .NET APIs, and eliminates the need for custom interfaces. Only use Option 2 if you require custom cancellation logic that CancellationToken doesn’t support.

内容的提问来源于stack exchange，提问作者Ross Halliday