使用Azure WebJobs SDK的依赖注入

本文关键字:依赖 注入 SDK Azure WebJobs 使用 | 更新日期: 2023-09-27 17:50:01

问题是Azure WebJobs SDK只支持公共静态方法作为作业入口点,这意味着没有办法实现构造函数/属性注入。

我无法在官方WebJobs SDK文档/资源中找到有关此主题的任何内容。我遇到的唯一解决方案是基于这篇文章中描述的服务定位器(反)模式。

是否有一个好方法来使用"适当的"依赖注入基于Azure WebJobs SDK的项目?

使用Azure WebJobs SDK的依赖注入

Azure WebJobs SDK现在支持实例方法。将它与自定义IJobActivator结合使用,可以使用DI。

首先,创建可以使用您最喜欢的DI容器解析作业类型的自定义IJobActivator:

public class MyActivator : IJobActivator
{
    private readonly IUnityContainer _container;
    public MyActivator(IUnityContainer container)
    {
        _container = container;
    }
    public T CreateInstance<T>()
    {
        return _container.Resolve<T>();
    }
}

你需要使用一个自定义的JobHostConfiguration来注册这个类:

var config = new JobHostConfiguration
{
    JobActivator = new MyActivator(myContainer)
};
var host = new JobHost(config);

然后,你可以使用一个简单的类实例方法为你的工作(这里我使用Unity的构造函数注入功能):

public class MyFunctions
{
    private readonly ISomeDependency _dependency;
    public MyFunctions(ISomeDependency dependency)
    {
        _dependency = dependency;
    }
    public Task DoStuffAsync([QueueTrigger("queue")] string message)
    {
        Console.WriteLine("Injected dependency: {0}", _dependency);
        return Task.FromResult(true);
    }
}

这就是我使用新SDK处理作用域的方式。使用Alexander Molenkamp所描述的IJobactivator

public class ScopedMessagingProvider : MessagingProvider
{
    private readonly ServiceBusConfiguration _config;
    private readonly Container _container;
    public ScopedMessagingProvider(ServiceBusConfiguration config, Container container)
        : base(config)
    {
        _config = config;
        _container = container;
    }
    public override MessageProcessor CreateMessageProcessor(string entityPath)
    {
        return new CustomMessageProcessor(_config.MessageOptions, _container);
    }
    private class CustomMessageProcessor : MessageProcessor
    {
        private readonly Container _container;
        public CustomMessageProcessor(OnMessageOptions messageOptions, Container container)
            : base(messageOptions)
        {
            _container = container;
        }
        public override Task<bool> BeginProcessingMessageAsync(BrokeredMessage message, CancellationToken cancellationToken)
        {
            _container.BeginExecutionContextScope();
            return base.BeginProcessingMessageAsync(message, cancellationToken);
        }
        public override Task CompleteProcessingMessageAsync(BrokeredMessage message, FunctionResult result, CancellationToken cancellationToken)
        {
            var scope = _container.GetCurrentExecutionContextScope();
            if (scope != null)
            {
                scope.Dispose();
            }
            return base.CompleteProcessingMessageAsync(message, result, cancellationToken);
        }
    }
}

您可以在JobHostConfiguration中使用自定义MessagingProvider,如

var serviceBusConfig = new ServiceBusConfiguration
{ 
    ConnectionString = config.ServiceBusConnectionString
};
serviceBusConfig.MessagingProvider = new ScopedMessagingProvider(serviceBusConfig, container);
jobHostConfig.UseServiceBus(serviceBusConfig);

在问了我自己关于如何处理作用域的问题之后…我刚刚想到了一个解决办法,我觉得这个办法不太理想,但是目前我找不到其他的办法。

在我的例子中,我正在处理ServiceBusTrigger。

当我使用SimpleInjector时,IJobActivator接口的实现看起来像这样:

public class SimpleInjectorJobActivator : IJobActivator
{
    private readonly Container _container;
    public SimpleInjectorJobActivator(Container container)
    {
        _container = container;
    }
    public T CreateInstance<T>()
    {
        return (T)_container.GetInstance(typeof(T));
    }
}

这里,我正在处理触发的webjobs。

所以我有两个依赖项:

  • 单:

    public interface ISingletonDependency { }
    public class SingletonDependency : ISingletonDependency { }
    
  • 另一个只需要在我的函数被触发的时候存在:

    public class ScopedDependency : IScopedDependency, IDisposable
    {
        public void Dispose()
        {
             //Dispose what need to be disposed...
        }
    }
    

所以为了有一个独立于webjob运行的进程。我已经将我的过程封装到一个类中:

public interface IBrokeredMessageProcessor
{
    Task ProcessAsync(BrokeredMessage incommingMessage, CancellationToken token);
}
public class BrokeredMessageProcessor : IBrokeredMessageProcessor
{
    private readonly ISingletonDependency _singletonDependency;
    private readonly IScopedDependency _scopedDependency;
    public BrokeredMessageProcessor(ISingletonDependency singletonDependency, IScopedDependency scopedDependency)
    {
        _singletonDependency = singletonDependency;
        _scopedDependency = scopedDependency;
    }
    public async Task ProcessAsync(BrokeredMessage incommingMessage, CancellationToken token)
    {
        ...
    }
}

所以现在当webjob启动时,我需要根据它们的作用域注册我的依赖项:

class Program
{
    private static void Main()
    {
        var container = new Container();
        container.Options.DefaultScopedLifestyle = new ExecutionContextScopeLifestyle();
        container.RegisterSingleton<ISingletonDependency, SingletonDependency>();
        container.Register<IScopedDependency, ScopedDependency>(Lifestyle.Scoped);
        container.Register<IBrokeredMessageProcessor, BrokeredMessageProcessor>(Lifestyle.Scoped);
        container.Verify();
        var config = new JobHostConfiguration
        {
            JobActivator = new SimpleInjectorJobActivator(container)
        };
        var servicebusConfig = new ServiceBusConfiguration
        {
            ConnectionString = CloudConfigurationManager.GetSetting("MyServiceBusConnectionString")
        };
        config.UseServiceBus(servicebusConfig);
        var host = new JobHost(config);
        host.RunAndBlock();
    }
}

这是被触发的作业:

    只有一个依赖项:IoC容器。因为这个类是我的作文根的一部分,所以应该没问题。
  • 它将作用域处理为触发函数。

    public class TriggeredJob
    {
        private readonly Container _container;
        public TriggeredJob(Container container)
        {
            _container = container;
        }
        public async Task TriggeredFunction([ServiceBusTrigger("queueName")] BrokeredMessage message, CancellationToken token)
        {
            using (var scope = _container.BeginExecutionContextScope())
            {
                var processor = _container.GetInstance<IBrokeredMessageProcessor>();
                await processor.ProcessAsync(message, token);
            }
        }
    }
    

这个问题的所有答案现在都过时了。使用最新的包,您可以轻松地获得构造函数注入。只需要两个步骤:

  1. 将事件处理函数创建为非静态类中的实例方法。我们称这个类为QueueFunctions

  2. 将您的类添加到服务列表中。

     builder.ConfigureServices(services =>
     {
         // Add 
         // dependencies
         // here
         services.AddScoped<QueueFunctions>();
     });
    

现在,你可以通过构造函数注入依赖项了。

我使用了几个依赖于子容器/作用域概念的模式(取决于您所选择的IoC容器的术语)。不确定哪些支持它,但我可以告诉你StructureMap 2.6。x和AutoFac可以。

思路是为每个传入的消息启动子作用域,注入该请求的唯一上下文,从子作用域解析顶级对象,然后运行您的进程。

下面是一些通用代码,用AutoFac显示它。它确实从容器进行直接解析,类似于您试图避免的反模式,但它被隔离在一个地方。

在这种情况下,它使用ServiceBusTrigger来触发作业,但可以是任何东西-作业主机可能有不同队列/进程的这些列表。

public static void ServiceBusRequestHandler([ServiceBusTrigger("queuename")] ServiceBusRequest request)
{
   ProcessMessage(request);
}

该方法被上述方法的所有实例调用。它将子范围的创建封装在using块中,以确保一切都被清理干净。然后,将创建每个请求不同且包含其他依赖项(用户/客户端信息等)使用的上下文的任何对象,并将其注入子容器(在本例中为IRequestContext)。最后,执行该工作的组件将从子容器中解析。

private static void ProcessMessage<T>(T request) where T : IServiceBusRequest
{
    try
    {
        using (var childScope = _container.BeginLifetimeScope())
        {
            // create and inject things that hold the "context" of the message - user ids, etc
            var builder = new ContainerBuilder();
            builder.Register(c => new ServiceRequestContext(request.UserId)).As<IRequestContext>().InstancePerLifetimeScope();
            builder.Update(childScope.ComponentRegistry);
            // resolve the component doing the work from the child container explicitly, so all of its dependencies follow
            var thing = childScope.Resolve<ThingThatDoesStuff>();
            thing.Do(request);
        }
    }
    catch (Exception ex)
    {
    }
}