Consumer vs Handler

[faze...@free.fr]

Hi,

I'd like to know the exact difference between those two receive mechanisms. 

I know from the doc, handlers should be less flexible because we cannot control the lifecycle. Consumers seems to be the way to go, BUT I got two concerns :

- first, I use LightInject as IoC container, and for now, there's no support for it (I've started my own receipe, it seems feasable)

- second (and most important), I don't want to include MassTransit in my domain logic (IConsumer<T>), so I have custom interfaces for receiver (ie. IHandleEvent<TEvent>, IHandleCommand<TCommand> => CQRS/ES style). I've tried to adapt mine into MT's but it doesn't seem that easy (using Consume(consumerType, consumerFactory) seems to be the right way but it makes me use tons of reflection at the moment of handling messages).

So my question is the following : in what way is it better to use consumers, and what do I gain ?

By the way, I've been playing around with MT3, cool async APIs :)

Best Regards,

Franck.

[Chris Patterson]

With consumers you get life cycle management, exactly as you stated. You also get dependency management (which is similar to lifecycle management, but worth calling out separately). You also get the ability to consume multiple message types -- some would call this a smell, and a violation of the single-responsibility principle -- which can be useful when events are similar enough but not the same.

May have tried to map their own domain-specific IHandleXxx interfaces to MT for consumers, the discovery is the key to make it work though. If you look at the ConsumerConnector (and related types) you can see how discovery is performed and the method adapters are bound to the endpoints. The coupling of IConsumer<T> is minimal, but if you want to avoid it it's certainly possible to create your own connectors for your own interface types.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/a8bb4760-dfe1-47fe-9196-fd6f8e141ad1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Patterson]

I forgot to mention, losing access to the Consume Context (which provides access to headers, as well as methods scoped to the message) is a pretty big deal if the consumer is participating in a conversation with other endpoints.

[faze...@free.fr]

Thank you for those intel. For now, I've managed to make may custom adapters ... adapt (duh !) my custom handlers. All with a Lightinject extensions (kinda inspired by the autofac ones). I can contribute and send them to you if you want.

Regards.

[David Nichol]

I'm coming quite late to this discussion, but what are some situations where I would want to use Handlers instead of Consumers?

[Chris Patterson]

I rarely if ever use handlers outside of proof of concept or testing. The construct is present to make it possible to bind other message handling mechanisms and frameworks to bind to MassTransit receive endpoints and leverage the features of MassTransit without taking a full dependency on it throughout a domain model. 

__
Chris Patterson

--

You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/1e706c50-6d76-463d-b1e3-67853e2513cf%40googlegroups.com.