具有依赖注入的 CQRS
CQRS with Dependency Injection
这应该是一个非常快速的问题。我正在尝试学习 CQRS 模式,但有一件事尚不清楚。有两个调度程序:用于命令和查询。它们都需要注入 DI 内核才能获得适当的处理程序。例如:
var handler = _resolver.Resolve<IQueryHandler<TQuery, TResult>>();
这不是违背了DI的概念,Resolve绝对不能用,什么都用constructor/properties注入吗?
还有一个更大的例子:http://www.adamtibi.net/06-2013/implementing-a-cqrs-based-architecture-with-mvc-and-document-db
请查看此方法:
public void Dispatch<TParameter>(TParameter command) where TParameter : ICommand
{
var handler = _kernel.Get<ICommandHandler<TParameter>>();
handler.Execute(command);
}
我在 3 个不同的页面上找到了这个解决方案。为什么这样做而不是创建工厂将Query映射到QueryHandler?
如果您认为调度程序是基础架构的一部分,那么在其中调用 Resolve() 并不违反您描述的 DI 概念。
处理程序通常被认为是逻辑管道(或线程,或者你想怎么想)的入口点。这类似于 MVC 中的控制器,或控制台应用程序中的 Main() 方法。因此,与这些其他构造一样,调度程序被认为是依赖链中的顶级对象,因此是引用容器的完全合法的地方。
编辑
所以评论提到了组合根(CR),这是一个我喜欢但在这个答案中有意避免的术语,因为它容易让人感到困惑。 CR 是特定的 class 吗?大会?我倾向于将其更多地视为一个概念,而不是一个特定的结构。这是组成对象图的应用程序中的逻辑位置。
澄清我对控制器的意思:控制器将是入口点,并且(如@Zbigniew 指出的那样)控制器工厂将是 CR(的一部分)。同样,处理程序将是入口点,而调度程序将是 CR。 Handlers/Controllers 不会引用容器,但 Dispatcher/ControllerFactory 会。
这应该是一个非常快速的问题。我正在尝试学习 CQRS 模式,但有一件事尚不清楚。有两个调度程序:用于命令和查询。它们都需要注入 DI 内核才能获得适当的处理程序。例如:
var handler = _resolver.Resolve<IQueryHandler<TQuery, TResult>>();
这不是违背了DI的概念,Resolve绝对不能用,什么都用constructor/properties注入吗?
还有一个更大的例子:http://www.adamtibi.net/06-2013/implementing-a-cqrs-based-architecture-with-mvc-and-document-db
请查看此方法:
public void Dispatch<TParameter>(TParameter command) where TParameter : ICommand
{
var handler = _kernel.Get<ICommandHandler<TParameter>>();
handler.Execute(command);
}
我在 3 个不同的页面上找到了这个解决方案。为什么这样做而不是创建工厂将Query映射到QueryHandler?
如果您认为调度程序是基础架构的一部分,那么在其中调用 Resolve() 并不违反您描述的 DI 概念。
处理程序通常被认为是逻辑管道(或线程,或者你想怎么想)的入口点。这类似于 MVC 中的控制器,或控制台应用程序中的 Main() 方法。因此,与这些其他构造一样,调度程序被认为是依赖链中的顶级对象,因此是引用容器的完全合法的地方。
编辑
所以评论提到了组合根(CR),这是一个我喜欢但在这个答案中有意避免的术语,因为它容易让人感到困惑。 CR 是特定的 class 吗?大会?我倾向于将其更多地视为一个概念,而不是一个特定的结构。这是组成对象图的应用程序中的逻辑位置。
澄清我对控制器的意思:控制器将是入口点,并且(如@Zbigniew 指出的那样)控制器工厂将是 CR(的一部分)。同样,处理程序将是入口点,而调度程序将是 CR。 Handlers/Controllers 不会引用容器,但 Dispatcher/ControllerFactory 会。