到目前为止,我已经做到了这些:
// enables contravariant Resolve() for interfaces with single contravariant ("in") arg
builder
.RegisterSource(new ContravariantRegistrationSource());
// mediator itself
builder
.RegisterType<Mediator>()
.As<IMediator>()
.InstancePerLifetimeScope();
// request handlers
builder
.Register<SingleInstanceFactory>(context => {
var ctx = context.Resolve<IComponentContext>(); // unsure why needed, but it works
return t => { object o; return ctx.TryResolve(t, out o) ? o : null; };
})
.InstancePerLifetimeScope();
// notification handlers
builder
.Register<MultiInstanceFactory>(context => {
var ctx = context.Resolve<IComponentContext>(); // unsure why needed, but it works
return t => (IEnumerable<object>)ctx.Resolve(typeof(IEnumerable<>).MakeGenericType(t));
})
.InstancePerLifetimeScope();
然后注册我的自定义内容:
- 处理程序为瞬态,即
InstancePerDependency()
- 前/后处理器为每个请求,即
InstancePerLifetimeScope()
- 行为为瞬态,即
InstancePerDependency()
例如:
builder.RegisterType<EditCommandHandler>().AsImplementedInterfaces().InstancePerDependency();
然而,在我看到的大多数代码示例中,特别是对于StructureMap,还有许多其他的注册(例如:
IRequestHandler<,>
,IRequestHandler<>
,IAsyncRequestHandler<,>
,IAsyncRequestHandler<>
,ICancellableAsyncRequestHandler<,>
,ICancellableAsyncRequestHandler<>
,INotificationHandler<>
,IAsyncNotificationHandler<>
,ICancellableAsyncNotificationHandler<>
),而且ASP.NET Core容器的集成也非常复杂。我没有做过类似的事情。如果您已经在生产中使用此功能,请问您的配置与我的相比如何?谢谢!
var ctx = context.Resolve<IComponentContext>()
吗?似乎这是不必要的,因为context
解析到相同的内容,但如果你将其排除,则无法解析。 - grokkyt => { object o; return ctx.TryResolve(t, out o) ? o : null; };
),而在Register
方法中提供的原始IComponentContext
实例无法被捕获。虽然它解析到相同的类型,但我认为它不会解析到相同的实例。但是,不幸的是,我无法提供更详细的解释。 - Mickaël Derriey.GetHashCode()
,结果它们是相同的。所以似乎这是不必要的,但是如果你删除它,它会失败。很奇怪,但我并不在意,因为它可以工作。 - grokky