tags:

views:

36

answers:

1

The simplest way to follow this explanation is a NServiceBus Pub/Sub sample which contains example of "polymorphic subscriptions" (Subscriber2).

Messages: (without changes)

public class EventMessage : IEvent
{
    public Guid EventId { get; set; }
    public DateTime? Time { get; set; }
    public TimeSpan Duration { get; set; }
}

public interface IEvent : IMessage
{
    Guid EventId { get; set; }
    DateTime? Time { get; set; }
    TimeSpan Duration { get; set; }
}

Handler: (without changes)

public class EventMessageHandler : IHandleMessages<IEvent>
{
    public void Handle(IEvent message)
    {
        // ...
    }
}

This handler will receive both IEvent and EventMessage messages. But if I will make IEvent a class...

public class IEvent : IMessage
{
    Guid EventId { get; set; }
    DateTime? Time { get; set; }
    TimeSpan Duration { get; set; }
}

...then i will not be able to receive EventMessage but will receive IEvent as before

So i found such simple rule: if you use interface in IHandleMessages<> - it will work, if class - it will not work. Currently i have all messages as classes and i would like to subscribe to parent class message in order to receive all child class messages.

Is it intended behavior?

+2  A: 

This is all by design in order to enable multiple inheritance. The reasons to do so are detailed here. Publicly available events between Business Components are recommended to be modeled as interfaces, commands within a business component are recommended to be modeled as classes. Sounds like you want this behaviour, I would switch over to interfaces.

Adam Fyles