Windows Azure Service Bus Queues - MessageSender or QueueClient?

Question

Backstory:

A few months ago (when I was new to Azure Queues and the SDK tools out there) I Googled "how do I do this" and "how do I do that"... here is where I am today:

1. I'm using a QueueClient (Microsoft.ServiceBus.Messaging - Microsoft.ServiceBus.dll) to receive messages from an Azure Queue.

2. In my same program I'm also using a MessageSender (from the same namespace and dll) to send messages to the Azure Queue.

3. My program has to track a Dictionary<string, QueueClient> and a Dictionary<string, MessageSender> - which is more complicated than it should be.

Now that I'm more familiar with the Azure SDKs... I realize that the QueueClient class can both send and receive... So why am I keeping track of 2 objects when the first one can do both?

Question:

Is there any reason to use the MessageSender class instead of the QueueClient class?

If I need to send and receive, shouldn't I just use the QueueClient class?

Answer 1

OK - I should have just reflected the DLL first... found the answer.

QueueClient is a class that simply has a MessageSender object and a MessageReceiver object inside of it. So the answer is "No, you should not have 2 objects to do the same thing".

Reflected code of the "Send" method:

public void Send(BrokeredMessage message)
{
    this.ThrowIfSenderNull("Send");
    this.InternalSender.Send(message);
}

The "InternalSender" object above is of type MessageSender.

Answer 2

We have exposed the two different object to support symmetry and ease-of-use. As you are aware we have Topics/Subscriptions as well as Queues. If you are just using Queues then you can create a QueueClient and achieve all the operations needed thru that. But say you later wanted to move to a Topic/Subscription publish-subscribe model. Programming against a generic MessageSender and MessageReciever will allow you to change the underlying topology and not have to modify any code (just the address urls/names). Thus you can write code that can work both in Queue as well as Topic/Subscription scenarios.