Query Processing

从3.1版本开始，Axon Framework还提供了用于查询处理的组件。虽然创建这样的一个层次是非常直接的，但是对于这部分应用程序使用Axon Framework有很多好处，比如拦截器和消息监视等功能的重用。

下一节将概述与使用Axon Framework设置查询分发基础架构有关的任务。

Query Gateway

Query Gateway是查询调度机制的一个便利接口。虽然不需要使用网关来发送查询，但这通常是最简单的选择。 Axon提供了QueryGateway接口和DefaultQueryGateway实现。 Query Gateway提供了许多方法，允许您发送查询并同步等待一个或多个结果，具有超时或异步操作。查询网关需要配置访问查询总线和QueryDispatchInterceptors列表（可能为空）。

Query Bus

查询总线是将查询分发给查询处理程序的机制。查询使用查询请求名称和查询响应类型的组合进行注册。可以为相同的请求 - 响应组合注册多个处理程序，这可以用来实现分散 - 收集模式。当分发查询时，客户端必须指出是否需要单个处理程序或所有处理程序的响应。

如果客户端请求来自单个处理程序的响应，并且找不到对应的处理程序，则会引发NoHandlerForQueryException。如果注册了多个处理程序，则由查询总线的实现决定哪个处理程序实际被调用。

如果客户端请求是针对所有的handlers的话，那么这个返回结果会是一个流。如果客户端请求所有处理程序的响应，则返回结果流。该流包含了来自每个处理程序的成功处理查询的结果，但是他们是无序的。如果查询没有找到合适处理程序，或者所有处理程序在处理请求时都抛出异常，则该流为空。

SimpleQueryBus

SimpleQueryBus是Axon 3.1中唯一的Query Bus实现。它在调度它的线程中直接处理查询。 SimpleQueryBus允许配置拦截器，请参阅查询拦截器了解更多信息。

Query Interceptors

使用查询总线的优点之一是能够根据所有传入的查询进行操作。比如日志记录或身份验证，无论查询的类型如何，您都可能想要执行此操作。我们可以用拦截器来完成这些要求。

axon提供了两种不同类型的拦截器：调度拦截器和处理器拦截器。调度拦截器是在将查询分发给查询处理程序之前调用，但是此时他不能确定该查询是否存在相匹配的处理程序。处理程序拦截器在调用查询处理程序之前被调用。

Dispatch Interceptors

在查询总线上分发查询时调用消息分发拦截器。他们可以通过添加元数据来改变查询消息，或者通过抛出异常来阻止查询。这些拦截器总是在调度查询的线程上调用。在查询总线上分发查询时调用消息分发拦截器。他们通过添加元数据来改变查询消息，或者通过抛出异常来阻止查询。这些拦截器总是在调度查询的线程上调用。

Structural validation

如果查询不包括查询处理所必需信息，则处理查询毫无意义。事实上，一个缺乏正确信息的查询应该尽早被阻止。因此，拦截器应该校验所传入的查询的信息来判断他们的可用性，这就是所谓的结构验证。

Axon框架支持基于JSR 303 Bean Validation的验证。您可以使用@NotEmpty和@Pattern之类的注解来注解命令上的字段。您需要在类路径中包含JSR 303实现（如Hibernate-Validator）。然后，在你的查询总线上配置一个BeanValidationInterceptor，它会自动查找并配置你的验证器实现。虽然它使用合理的默认值，但您可以根据自己的特定需求进行微调。
建议：你想花尽可能少的资源在一个无效的命令上。所以这个拦截器一般都放在拦截器链的最前面。在某些情况下，你须要将日志记录或Auditing 拦截器放置在前面，而紧接着在后面添加一个验证拦截器。
BeanValidationInterceptor也实现了MessageHandlerInterceptor，允许你配置它为Handler Interceptor。

Handler Interceptors

消息处理程序拦截器可以在查询处理之前和之后执行操作。拦截器甚至可以完全阻止查询处理，例如由于安全原因引起的。

拦截器必须实现MessageHandlerInterceptor接口。这个接口声明了一个方法handle，它有三个参数：查询消息，当前的UnitOfWork和一个InterceptorChain。 InterceptorChain用于继续调度处理。

与Dispatch 拦截器不同，他是在查询处理程序的上下文中调用处理程序拦截器。这意味着他们可以将正在处理的消息的关联数据附加到工作单元。然后将这个关联数据附加到在该工作单元的上下文中创建的消息。