为泛型接口配置装饰器，并在简单注入器中将所有实例注入到具有非泛型接口参数的构造函数

我一直在使用与所描述的非常相似的模式在这篇优秀的文章中 http://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=91将命令和查询作为对象。我还使用 SimpleInjector 作为 DI 容器。

唯一显着的区别是控制器显式依赖于某些ICommandHandler<TCommand>我希望控制器依赖于一个对象（一个Dispatcher）这将需要ICommand实例并解析该命令的正确处理程序。这将减少构造函数需要采用的参数数量，并使整个过程更容易使用。

So my Dispatcher对象构造函数如下所示：

public CommandAndQueryDispatcher(IEnumerable<ICommandHandler> commandHandlers,
    IEnumerable<IQueryHandler> queryHandlers)
{
}

我的 CommandHandler 接口如下所示：

public interface ICommandHandler<in TCommand> : ICommandHandler 
    where TCommand : ICommand
{
    void Execute(TCommand command, ICommandAndQueryDispatcher dispatcher);
}

public interface ICommandHandler
{
    void Execute(object command, ICommandAndQueryDispatcher dispatcher);
}

典型的命令处理程序如下所示：

public abstract class CommandHandlerBase<TCommand> : ICommandHandler<TCommand> 
    where TCommand : ICommand
{
    public abstract void Execute(TCommand command, ICommandAndQueryDispatcher dispatcher);

    public void Execute(object command, ICommandAndQueryDispatcher dispatcher)
    {
        Execute((TCommand) command, dispatcher);
    }
}

internal class DeleteTeamCommandHandler : CommandHandlerBase<DeleteTeamCommand>
{
    public DeleteTeamCommandHandler(){        }

    public override void Execute(DeleteTeamCommand command, 
        ICommandAndQueryDispatcher dispatcher)
    {
       ... functionality here...
    }
}

然而，这种变化有一些影响，现在我想在我的命令和查询中添加一些装饰器，但我遇到了一些问题。

为了将所有命令和查询注入到Dispatcher我让它们都有一个基础的、非通用的界面ICommandHandler and IQueryHandler，然后询问实际接收到的实例（这是通用的）以获取它们处理的命令类型以注册它们，以便我稍后可以根据给定命令的类型查找处理程序。

现在，当我尝试使用示例中所示的装饰器时，我似乎无法将任何内容注入到我的Dispatcher，由于装饰实例被注册为泛型类型，因此不会被解析为基本类型ICommandHandler实例。如果我尝试使装饰器成为非通用的，那么注入的实例没有任何通用类型参数，因此我无法找到其处理程序的命令类型。

我觉得我一定错过了一些相当简单的东西。

所以我的问题是

• 如何从容器中获取开放泛型类型的所有实例作为基本接口传递到我的Dispatcher?

OR

• 有没有更好的方法来实现调度程序功能，以便我的控制器可以不知道哪个处理程序将处理与 SimpleInjector 配合得更好的命令/查询？

这将减少构造函数所需的参数数量 使整个东西更容易使用

请密切关注这一点，因为这样做可能会掩盖您的控制器做得太多的事实；违反单一责任原则 https://en.wikipedia.org/wiki/Single_responsibility_principle。违反 SRP 往往会导致以后出现可维护性问题。甚至还有一个后续文章 https://cuttingedge.it/blogs/steven/pivot/entry.php?id=92您提到的文章的作者（顺便说一句，就是我）指出：

我当然不会提倡 ICommandProcessor [那是 ICommandAndQueryDispatcher 在你的情况下]用于执行命令 - 消费者不太可能依赖许多命令 处理程序，如果他们这样做可能会违反 SRP。 （source https://cuttingedge.it/blogs/steven/pivot/entry.php?id=92)

本文甚至讨论了查询的解决方案，但您也可以将其应用到您的命令中。但您应该考虑剥离您的解决方案并删除非通用接口。你不需要它们。

相反，定义以下内容：

public interface ICommandHandler<TCommand> : where TCommand : ICommand
{
    void Execute(TCommand command);
}

请注意以下几点：

1. 没有非通用接口。
2. 你没有通过ICommandAndQueryDispatcher。那太丑了。这ICommandAndQueryDispatcher是一个服务，并且服务需要通过构造函数注入来传递。这command另一方面是运行时数据，并且运行时数据使用方法参数传递 https://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=99。因此，如果有一个命令或查询处理程序需要调度程序：通过构造函数注入它。
3. 没有in关键字为TCommand。由于命令是用例，因此应该命令和命令处理程序实现之间的一对一映射。然而，指定“in”意味着一个命令类可以映射到多个处理程序，但情况不应如此。另一方面，当处理事件和事件处理程序时，这将是一种更明显的方法。
4. No more CommandHandlerBase<TCommand>。你不需要那个。我认为好的设计几乎不需要基类。

另一件事是，不要尝试将命令调度程序与查询调度程序混合在一起。两种责任意味着两种阶级。这是您的命令调度程序的外观：

// This interface is defined in a core application layer
public interface ICommandDispatcher
{
    void Execute(ICommand command);
}

// This class is defined in your Composition Root (where you wire your container)
// It needs a dependency to the container.
sealed class CommandDispatcher : ICommandDispatcher
{
    private readonly Container container;

    public CommandDispatcher(Container container) {
        this.container = container;
    }

    public void Execute(ICommand command) {
        var handlerType = typeof(ICommandHandler<>)
            .MakeGenericType(command.GetType());

        dynamic handler = container.GetInstance(handlerType);

        handler.Handle((dynamic)command);
    }
}

请注意，您不会在此处注入命令处理程序的集合，而是从容器请求处理程序。该代码仅包含基础设施，没有业务逻辑，因此，如果您将此实现靠近负责连接容器的代码，您将not http://blog.ploeh.dk/2011/08/25/ServiceLocatorrolesvs.mechanics/滥用服务定位器反模式 http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/，这是一个有效的方法。在这种情况下，应用程序的其余部分仍然不依赖于 DI 框架。

你可以注册这个CommandDispatcher如下：

container.RegisterSingle<ICommandDispatcher>(new CommandDispatcher(container));

如果您采用这种方法，因为您通过ICommandHandler<TCommand>接口，容器将自动使用必须根据您的配置和您应用的通用类型约束应用的任何装饰器来包装处理程序。