0

目立たない NServiceBus サンプルでは、​​次のように、エンドポイント構成でインバウンド メッセージを ICommand / IEvent / IMessage にマップする方法を説明しています。

.DefiningCommandsAs(t => t.Namespace != null && t.Namespace.EndsWith("Commands"))
.DefiningEventsAs(t => t.Namespace != null && t.Namespace.EndsWith("Events"))
.DefiningMessagesAs(t => t.Namespace == "Messages")

しかし、次の例では、マーカー インターフェイスを作成し、すべてのイベントでそれを実装したいと考えています。

public interface IAmSomeEvent
{
}

public class SomethingImportantHappenned : IAmSomeEvent
{
    public string blah { get; set; }
}

そして、次のようにします。

.DefiningEventsAs(t => t.GetInterfaces().Contains(typeof(IAmSomeEvent)))

しかし、これの問題は機能しないことです (NSB はこれを IEvent にマップしません)。

NSB が json (または XML) のストリームを受信して​​いるだけなので、これが機能しない理由がちょっとわかります。そのため、元の型がたまたま何らかのインターフェイスなどを実装することはあまり気にしません。しかし、それは非常に優れた機能になります。

これを達成する方法について何か提案はありますか?

どうもありがとう

4

1 に答える 1

4

NServiceBusのインターフェースにマップするためのインターフェースは必要ありません。また、逆シリアル化の方法に関係する問題もありません。

あなたのイベントはそれ自体があなたのマーカーインターフェースから継承する何かから継承していると思います、そしてそれがあなたのコードが機能しない理由です。ご覧のとおり、GetInterfacesは、クラスによって直接実装されたインターフェイスのみを返し、完全な継承階層は返しません。

代わりに、t.IsAssignableFrom（typeof（IAmSomeEvent））かどうかを確認してください。

とはいえ、この点がよくわかりません。結局のところ、パブリッシャーとサブスクライバーが異なるバージョンのNServiceBusに依存できるように、インフラストラクチャからの分離を提供するための規則が導入されました。独自のインターフェースを導入することで、そのような依存関係を再導入しているように見えます。つまり、NServiceBus IEventインターフェースを使用しないのはなぜですか？

于 2012-12-31T14:18:53.057 に答える