MassTransit 3.2.1-验证 [英] MassTransit 3.2.1 - Validation

问题描述

我想使用我的情况下的FluentValidation验证传入的消息，如果失败，则应立即返回.我调查了 http://docs.masstransit-project.com/en/Latest/usage/observers.html ，就我而言，我喜欢

I want to validate an incoming message, using FluentValidation in my case, and if it fails it should return immediately. I looked into http://docs.masstransit-project.com/en/latest/usage/observers.html, and in my case, I like the idea of

public class ConsumeObserver : IConsumeObserver
    {
    Task IConsumeObserver.PreConsume<T>(ConsumeContext<T> context)
    {
        //1.Validate here
        //2. If success go on to consumer
        //3. If fails exit with the result of validation and don't go through consumer.
    }

    Task IConsumeObserver.PostConsume<T>(ConsumeContext<T> context)
    {

    }

    Task IConsumeObserver.ConsumeFault<T>(ConsumeContext<T> context, Exception exception)
    {

    }
}

因为我已经将该消息反序列化了，所以易于使用验证器.问题是我不知道如何不经过消费者就不退货，同时又保留了验证错误.

because I get the message already deserialized and so is easy to use the validator. The problem is that I don't know how to return without going through consumer and a the same time keep the validation errors.

谢谢.

推荐答案

观察者通常观察与采取行动，这就是MassTransit中观察者的方法.虽然您可以从PreConsume方法引发异常，这将导致消息重试或被发送到错误队列，但对于不了解消息失败原因的开发人员而言，这并不是最明显的行为.

Observers typically watch versus take action, and that's the approach with observers in MassTransit. While you could throw an exception from the PreConsume method, which would cause the message to either retry or be sent to the error queue, it's not the most obvious behavior to developers down the road who may not understand why the message is failing.

另一种方法是创建可以验证消息的中间件组件，如果该消息无效，则对消息执行特定的操作(例如将其移动到无效队列，将其转储到日志等).以便将消息从队列中删除.重要的是要了解这可能如何影响消息生产者.

Another approach would be to create middleware component that can validate the message, and if it's not valid, perform a specific action on the message (such as moving it to an invalid queue, or dumping it to a log, or whatever) so that the message is removed from the queue. It's important to understand how this might impact the message producer.

例如，如果它是请求消息，而发送方正在等待响应，则丢弃该消息意味着将不会收到响应.引发异常的使用者的默认行为是将错误传播回请求者，从而完成了循环，因此请记住这一点.

For instance, if it was a request message, and the sender is waiting on a response, discarding the message means that no response will be received. The default behavior of a consumer that throws an exception is to propagate the fault back to the requestor, completing the cycle, so keep that in mind.

另一种选择是使用注入的验证接口或在使用者自身内部，仅将验证行为添加到使用者.这样，对消息的处理就接近于使用者，这提高了代码的内聚性，并使查看事件发生的过程变得容易.

Another option is to just add the validation behavior to the consumer, using either an injected validation interface, or within the consumer itself. That way, the handling of the message is close to the consumer which improves code cohesion and makes it easy to see what is happening.

理想情况下，在消息生产者处进行验证是最好的选择，以避免用无效消息淹没队列.这是另一种选择.

Ideally, validating at the message producer is the best option, to avoid flooding the queue with invalid messages. So that's another option.

因此，有几种选择，您的要求将决定哪种才是最合理的.

So, several choices, your requirements will dictate which makes the most sense.

这篇关于MassTransit 3.2.1-验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！