2010-10-05 4 views
2

La manière la plus simple de suivre cette explication est un exemple NServiceBus Pub/Sub qui contient un exemple de "abonnements polymorphes" (Subscriber2).Les abonnements polymorphes dans NServiceBus ne fonctionnent que pour les interfaces?

Messages: (sans modification)

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: (sans changement)

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

Ce gestionnaire recevra les messages IEvent et EventMessage. Mais si je vais faire IEvent une classe ...

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

... alors je ne serai pas en mesure de recevoirEventMessage mais recevront IEvent comme avant

donc j'ai trouvé cette règle simple: si vous utilisez l'interface dans IHandleMessages <> - cela fonctionnera, si classe - cela ne fonctionnera pas. Actuellement j'ai tous les messages comme classes et je voudrais m'abonner au message de classe de parent afin de recevoir tous les messages de classe d'enfant.

Est-ce un comportement intentionnel?

Répondre

3

Tout cela est inhérent à la conception afin de permettre l'héritage multiple. Les raisons de le faire sont détaillées here. Il est recommandé que les événements publiquement disponibles entre les composants métier soient modélisés en tant qu'interfaces. Il est recommandé de modéliser les commandes d'un composant métier en tant que classes. On dirait que vous voulez ce comportement, je passerais aux interfaces.

Questions connexes