使用Azure WebJobs SDK的依赖注入
本文关键字:依赖 注入 SDK Azure WebJobs 使用 | 更新日期: 2023-09-27 17:50:01
问题是Azure WebJobs SDK只支持公共静态方法作为作业入口点,这意味着没有办法实现构造函数/属性注入。
我无法在官方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); } } }
这个问题的所有答案现在都过时了。使用最新的包,您可以轻松地获得构造函数注入。只需要两个步骤:
-
将事件处理函数创建为非静态类中的实例方法。我们称这个类为
QueueFunctions
。 -
将您的类添加到服务列表中。
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)
{
}
}