[rabbitmq-discuss] Using .NET types as routing keys
alfonso.pantoja at gmail.com
Wed Apr 13 15:30:53 BST 2011
On 13 abr, 13:33, Mike Hadlow <mike.had... at 15below.com> wrote:
> Hi, I'm new to Rabbit MQ. I want to build a simple .NET API with methods like Publish<T>(T message). It strikes me that using the .NET type as the routing key would be a very elegant way routing messages. Has anyone used RabbitMQ like this? Is it a stupid idea?
In my opinion is good idea because there is no need to encapsulate
data into a container with a field "messageType"
since you hace the routing key in the AMQP header (so the consumer can
read it and deserialize the message according that)
As far as I know your options are:
1. Your routing keys can be namespaces or "non-namespace keys" that
you should map in a configuration file, for example, for translate it
to the proper namespace.
2. To instance your handlers with IoC (using Castle Project for
example) depending on your routing keys. This is the choice I tested
and works good.
3. Create queues which name is a namespace binded with a fanout
exchange and instancing there messages as using the queue name
(drawbacks are those queues only can contain 1 kind of message and you
are not using the "power" of routing keys). I wouldn't recommend this
4. Not using routing keys: To send your entities encapsulated in a
fixed container with at least 2 fields (messageBody, messageType).
Every time you receive a message you need to deserialize the envelope
and read the "messageType" field and deserialize the messageBody (it
should be an array of bytes) which holds your business entity. This
approach is not faster as others due to the need of deserialize twice.
More information about the rabbitmq-discuss