我在库中公开了处理消息代理的所有机制,客户端需要使用扩展方法来使用它,在我需要它提供实现IMessageHandler
接口的处理程序集合的情况下,该处理程序将处理每个订阅渠道。它可以工作,但是我的原型仅需要通过我想强类型输入的Func
进行依赖注入,以强制客户端提供预期的接口依赖注入。
这里是消息处理的界面:
public interface IMessageHandler
{
void HandleMessageAsync(object sender, MyEventArgs e);
}
以及我在lib中的扩展方法的原型:
public static IServiceCollection UseTheSuperMessageBroker(
this IServiceCollection services,
IConfiguration config,
params Func<IServiceCollection>[] handlers)
然后,客户端可以使用扩展方法:
services.UseTheSuperMessageBroker(Configuration,
handlers: new Func<IServiceCollection>[] {
() => services.AddSingleton<IMessageHandler, myMessageHandler1>(),
() => services.AddSingleton<IMessageHandler, myMessageHandler2>()
});
但是没有什么可以阻止客户端提供任何与IMessageHandler
接口无关的依赖项注入,实际上最后一个参数让我们可以这样做:
services.UseTheSuperMessageBroker(
Configuration,
handlers: new Func<IServiceCollection>[] {
() => services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>(),
() => services.AddSingleton(typeof(IMongoRepository<>), typeof(MongoRepository<>))
});
这是正在编译,但是没有预期。 所以有什么机制可以迫使Func
仅使用与IMessageHandler
接口相关的依赖项注入?
[我在库中公开了处理消息代理的所有机制,客户端需要使用扩展方法来使用它,在我需要它提供实现...的处理程序集合的情况下,] [
IServiceCollection
。实际上,这里的代码甚至不使用lambda本地语言,而是使用包含方法(即services
)的本地语言。本质上,只要ConfigureServices
中存在进行此操作的手段,就可以在这里进行如果这是您的要求,那就更好了,只使用IMessageHandler
类型的集合,然后在方法中注册这些类型,而不是使用Func
的集合。
public static IServiceCollection UseTheSuperMessageBroker(
this IServiceCollection services,
IConfiguration config,
params Type[] handlers)
services.UseTheSuperMessageBroker(Configuration,
handlers: new[] {
typeof(myMessageHandler1),
typeof(myMessageHandler2)
});
然后,在该方法内:
foreach (var handler in handlers) { services.AddSingleton(typeof(IMessageHandler), handler); }
从技术上讲,这不会阻止他们添加未实现
IMessageHandler
的类型,但是由于您要明确绑定到IMessageHandler
,因此如果这样做,它将失败。