在ASP.NET Core中创建内部使用Scoped服务的Quartz.NET宿主服务

在我的，我展示了如何使用asp.net core创建quartz.net托管服务并使用它来按计划运行后台任务。不幸的是，由于quartz.net api的工作方式，在quartz作业中使用scoped依赖项注入服务有些麻烦。说明下这篇文章部分采用机翻。

作者：依乐祝

译文地址：

原文地址：

在这篇文章中，我将展示一种简化工作中使用scoped服务的方法。您可以使用相同的方法来管理ef core的工作单元模式和其他面向切面的模型。

这篇文章是引申出来的，因此，如果您还没有阅读的话，建议您先阅读上篇文章。

回顾-自定义jobfactory和单例的ijob

在上篇博客的最后，我们有一个实现了ijob接口并向控制台简单输出信息的helloworldjob。

public class helloworldjob : ijob
{
    private readonly ilogger<helloworldjob> _logger;
    public helloworldjob(ilogger<helloworldjob> logger)
    {
        _logger = logger;
    }
    public task execute(ijobexecutioncontext context)
    {
        _logger.loginformation("hello world!");
        return task.completedtask;
    }
}

我们还有一个ijobfactory的实现，以便我们在需要时从di容器中检索作业的实例：

public class singletonjobfactory : ijobfactory
{
    private readonly iserviceprovider _serviceprovider;
    public singletonjobfactory(iserviceprovider serviceprovider)
    {
        _serviceprovider = serviceprovider;
    }
    public ijob newjob(triggerfiredbundle bundle, ischeduler scheduler)
    {
        return _serviceprovider.getrequiredservice(bundle.jobdetail.jobtype) as ijob;
    }
    public void returnjob(ijob job) { }
}

这些服务都在startup.configureservices()中以单例形式注册：

services.addsingleton<ijobfactory, singletonjobfactory>();
services.addsingleton<helloworldjob>();

对于这个非常基本的示例来说，这很好，但是如果您需要在ijob内部使用一些范围服务呢？例如，也许您需要使用ef core dbcontext遍历所有客户，并向他们发送电子邮件，并更新客户记录。我们假设这个任务为emailreminderjob。

权宜之计

我在上一篇文章中展示的解决方案是将iserviceprovider注入到您的ijob的文档中，手动创建一个范围，并从中检索必要的服务。例如：

public class emailreminderjob : ijob
{
    private readonly iserviceprovider _provider;
    public emailreminderjob( iserviceprovider provider)
    {
        _provider = provider;
    }
    public task execute(ijobexecutioncontext context)
    {
        using(var scope = _provider.createscope())
        {
            var dbcontext = scope.serviceprovider.getservice<appdbcontext>();
            var emailsender = scope.serviceprovider.getservice<iemailsender>();
            // fetch customers, send email, update db
        }
        return task.completedtask;
    }
}

在许多情况下，这种方法绝对可以。如果不是将实现直接放在工作内部（如我上面所做的那样），而是使用中介者模式来处理诸如工作单元或消息分发之类的跨领域问题，则尤其如此。

如果不是这种情况，您可能会受益于创建一个可以为您管理这些工作的帮助类。

quartzjobrunner

要解决这些问题，您可以创建一个ijob的“中间” 实现，这里我们命名为quartzjobrunner，该实现位于ijobfactory和要运行的ijob之间。我将很快介绍作业实现，但是首先让我们更新现有的ijobfactory实现以无论请求哪个作业，始终返回quartzjobrunner的实例，：

using microsoft.extensions.dependencyinjection;
using quartz;
using quartz.spi;
using system;
public class jobfactory : ijobfactory
{
    private readonly iserviceprovider _serviceprovider;
    public jobfactory(iserviceprovider serviceprovider)
    {
        _serviceprovider = serviceprovider;
    }
    public ijob newjob(triggerfiredbundle bundle, ischeduler scheduler)
    {
        return _serviceprovider.getrequiredservice<quartzjobrunner>();
    }
    public void returnjob(ijob job) { }
}

如您所见，该newjob()方法始终返回quartzjobrunner的实例。我们将在startup.configureservices()中将quartzjobrunner注册为单例模式，因此我们不必担心它没有被明确释放。

services.addsingleton<quartzjobrunner>();

我们将在quartzjobrunner中创建实际所需的ijob实例。quartzjobrunner中的job会创建范围，实例化ijob的请求并执行它：

using microsoft.extensions.dependencyinjection;
using quartz;
using system;
using system.threading.tasks;
public class quartzjobrunner : ijob
{
    private readonly iserviceprovider _serviceprovider;
    public quartzjobrunner(iserviceprovider serviceprovider)
    {
        _serviceprovider = serviceprovider;
    }
    public async task execute(ijobexecutioncontext context)
    {
        using (var scope = _serviceprovider.createscope())
        {
            var jobtype = context.jobdetail.jobtype;
            var job = scope.serviceprovider.getrequiredservice(jobtype) as ijob;
            await job.execute(context);
        }
    }
}

在这一点上，您可能想知道，通过添加这个额外的间接层，我们获得了什么好处？主要有以下两个主要优点：

• 我们可以将emailreminderjob注册为范围服务，并直接将任何依赖项注入其构造函数中
• 我们可以将其他横切关注点转移到quartzjobrunner类中。

作业可以直接使用作用域服务

由于作业实例是从iserviceprovder作用域中解析来的，因此您可以在作业实现的构造函数中安全地使用作用域服务。这使的emailreminderjob的实现更加清晰，并遵循构造函数注入的典型模式。如果您不熟悉di范围界定问题，则可能很难理解它们，因此任何对您不利的事情在我看来都是一个好主意：

[disallowconcurrentexecution]
public class emailreminderjob : ijob
{
    private readonly appdbcontext _dbcontext;
    private readonly iemailsender _emailsender;
    public emailreminderjob(appdbcontext dbcontext, iemailsender emailsender)
    {
        _dbcontext = dbcontext;
        _emailsender = emailsender;
    }
    public task execute(ijobexecutioncontext context)
    {
        // fetch customers, send email, update db
        return task.completedtask;
    }
}

这些ijob的实现可以使用以下任何生存期（作用域或瞬态）来在startup.configureservices()中注册（jobschedule仍然可以是单例）：

services.addscoped<emailreminderjob>();
services.addsingleton(new jobschedule(
    jobtype: typeof(emailreminderjob),
    cronexpression: "0 0 12 * * ?")); // every day at noon

quartzjobrunner可以处理横切关注点

quartzjobrunner处理正在执行的ijob的整个生命周期：它从容器中获取，执行并释放它（在释放范围时）。因此，它很适合处理其他跨领域问题。

例如，假设您有一个需要更新数据库并将事件发送到消息总线的服务。您可以在每个单独的ijob实现中处理所有这些问题，也可以将跨领域的“提交更改”和“调度消息”操作移到quartzjobrunner中。

这个例子显然是非常基础的。如果这里的代码适合您，我建议您观看吉米·博加德（jimmy bogard）的“六小段失败线”演讲，其中描述了一些问题！

public class quartzjobrunner : ijob
{
    private readonly iserviceprovider _serviceprovider;
    public quartzjobrunner(iserviceprovider serviceprovider)
    {
        _serviceprovider = serviceprovider;
    }
    public async task execute(ijobexecutioncontext context)
    {
        using (var scope = _serviceprovider.createscope())
        {
            var jobtype = context.jobdetail.jobtype;
            var job = scope.serviceprovider.getrequiredservice(jobtype) as ijob;
            var dbcontext = _serviceprovider.getrequiredservice<appdbcontext>();
            var messagebus = _serviceprovider.getrequiredservice<ibus>();
            await job.execute(context);
            // job completed, save dbcontext changes
            await dbcontext.savechangesasync();
            // db transaction succeeded, send messages
            await messagebus.dispatchasync();
        }
    }
}

这里的quartzjobrunner实现与上一个非常相似，但是在执行的我们请求的ijob之前，我们从di容器中解析了dbcontext和消息总线服务。当作业成功执行后（即未抛出异常），我们将所有未提交的更改保存在中dbcontext，并在消息总线上调度事件。

将这些方法移到quartzjobrunner中应该可以减少ijob实现中的重复代码，并且可以更容易地移到更正式的管道和其他模式（如果您希望以后这样做的话）。

可替代解决方案

我喜欢本文中显示的方法（使用中间quartzjobrunner类），主要有两个原因：

• 您的其他ijob实现不需要任何有关创建作用域的基础结构的知识，只需完成标准构造函数注入即可
• 在ijobfactory中不需要做做任何特殊处理工作。该quartzjobrunner通过创建和处理作用域隐式地处理这个问题。

但是，此处显示的方法并不是在工作中使用范围服务的唯一方法。马修·阿伯特（matthew abbot） 在这个文章中演示了一种方法，该方法旨在以正确处理运行后的作业的方式实现ijobfactory。它有点笨拙，因为你必须匹配接口api，但可以说它更接近你应该实现它的方式！我个人认为我会坚持使用这种quartzjobrunner方法，但是你可以选择最适合您的方法