1

我有一个使用 CQRS 和依赖注入的项目。系统的查询端很好。

对于系统的命令端，我选择使用队列：

BlockingQueue<Command> commandQueue;

这将存储从多个线程接收到的命令及其参数。这些命令都实现了一个带有执行方法的通用接口：

public interface Command extends Serializable {
    void execute();
}

Commands 的参数作为数据存储在 Command 接口的具体实现中。参数的类型和可能的数量将根据它所代表的命令而有所不同，使用这种结构意味着这个细节都被封装在命令队列逻辑之外。

这个想法是命令稍后由一个工作线程按顺序执行，该工作线程依次在每个命令上调用 execute()，而不关心它在后台是哪个命令。

这些命令只有在从队列中取出准备执行时才需要注入（这主要是因为我希望能够序列化命令，但也因为命令的执行需要与接收和排队的应用程序部分不同的模块他们）

我的问题是这样 的：因为命令需要等到它们从队列中取出来获取它们的依赖关系，所以我最终将一个轻包装的 Injector 传递给它们的“执行”方法，这样它们就可以自己创建一个对象图。这感觉更像是服务定位器模式，而不是依赖注入。

public interface Command extends Serializable {
    void execute(**ExecutorLocator locator**);
}

是否有我遗漏的东西，或者 DI 在堆栈中的某个点必须看起来像服务定位器是不可避免的？

4

1 回答 1

2

自从我接触 Java 代码以来已经有一段时间了，但是好的架构和设计并不局限于一种语言。

首先：ServiceLocator 是一种反模式。

第二：告诉，不要问。如果有任何东西从外部构建命令，不要让他们向定位器询问他们的依赖关系。

第三：我会创建为命令注册的处理程序，并且知道如何处理封装在命令中的信息。因此，您根本不需要注入或构建您的命令。设置您的处理程序并确保您的命令到达那里。

于 2012-08-13T20:52:24.420 回答