Autofac和Quartz.Net集成 [英] Autofac and Quartz.Net Integration

问题描述

有人有没有集成 autofac 和 Quartz.Net 的经验?如果是这样，最好在哪里控制生命周期管理-IJobFactory，在IJob的Execute中还是通过事件侦听器?

Does anyone have any experience integrating autofac and Quartz.Net? If so, where is it best to control lifetime management -- the IJobFactory, within the Execute of the IJob, or through event listeners?

现在，我正在使用自定义的autofac IJobFactory创建IJob实例，但是我没有一种简单的方法来插入IJobFactory中的ILifetimeScope来确保任何昂贵的资源注入到IJob中进行清理.作业工厂仅创建作业的实例并返回它.这是我目前的想法(希望有更好的想法...)

Right now, I'm using a custom autofac IJobFactory to create the IJob instances, but I don't have an easy way to plug in to a ILifetimeScope in the IJobFactory to ensure any expensive resources that are injected in the IJob are cleaned up. The job factory just creates an instance of a job and returns it. Here are my current ideas (hopefully there are better ones...)

• 看起来大多数AutoFac集成都以某种方式将ILifetimeScope包裹在它们创建的工作单元周围.明显的暴力方式似乎是将ILifetimeScope传递到IJob并让Execute方法创建子ILifetimeScope并在那里实例化任何依赖项.这似乎有点类似于服务定位器模式，这反过来似乎违反了autofac的精神，但这可能是确保正确处理范围的最明显方法.

• It looks like most AutoFac integrations somehow wrap a ILifetimeScope around the unit of work they create. The obvious brute force way seems to be to pass an ILifetimeScope into the IJob and have the Execute method create a child ILifetimeScope and instantiate any dependencies there. This seems a little too close to a service locator pattern, which in turn seems to go against the spirit of autofac, but it might be the most obvious way to ensure proper handling of a scope.

我可以插入一些Quartz事件，以处理Job执行堆栈的不同阶段，并在那里进行生命周期管理.这可能会做更多的工作，但是如果可以更清晰地分离关注点，那么可能值得.

I could plug into some of the Quartz events to handle the different phases of the Job execution stack, and handle lifetime management there. That would probably be a lot more work, but possibly worth it if it gets cleaner separation of concerns.

确保IJob是围绕IServiceComponent类型的简单包装，这将完成所有工作，并将其请求为Owned<T>或Func<Owned<T>>.我喜欢autofac的这种感觉，但是我不喜欢它不能对IJob的所有实现者严格执行.

Ensure that an IJob is a simple wrapper around an IServiceComponent type, which would do all the work, and request it as Owned<T>, or Func<Owned<T>>. I like how this seems to vibe more with autofac, but I don't like that its not strictly enforceable for all implementors of IJob.

推荐答案

在对Quartz.Net和IJob不太了解的情况下，我还是会提出一个建议.

Without knowing too much about Quartz.Net and IJobs, I'll venture a suggestion still.

考虑以下作业包装:

public class JobWrapper<T>: IJob where T:IJob
{
    private Func<Owned<T>> _jobFactory;

    public JobWrapper(Func<Owned<T>> jobFactory)
    {
        _jobFactory = jobFactory;
    }


    void IJob.Execute()
    {
        using (var ownedJob = _jobFactory())
        {
            var theJob = ownedJob.Value;
            theJob.Execute();
        }
    }
}

提供以下注册:

builder.RegisterGeneric(typeof(JobWrapper<>));
builder.RegisterType<SomeJob>();

作业工厂现在可以解决此包装器:

A job factory could now resolve this wrapper:

var job = _container.Resolve<JobWrapper<SomeJob>>();

注意:终身范围作为ownedJob实例的一部分创建的，在这种情况下，该实例的类型为Owned<SomeJob>. SomeJob所需的任何依赖项，例如InstancePerLifetimeScope或InstancePerDependency，都将与Owned实例一起创建和销毁.

Note: a lifetime scope will be created as part of the ownedJob instance, which in this case is of type Owned<SomeJob>. Any dependencies required by SomeJob that is InstancePerLifetimeScope or InstancePerDependency will be created and destroyed along with the Owned instance.

这篇关于Autofac和Quartz.Net集成的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！