с помощью nservicebus для подписки на конкретный тип сообщения

Question

Я изучаю использование nservicebus и задаюсь вопросом, как трудно было бы сделать следующее в топологии публикации/подписки.

Например, клиент (ы) подписывается на сообщения типа пользователя. Но подпишитесь только на подмножество этих сообщений, например пользовательские сообщения с пользовательскими ключами 111,222, xxx и т. Д.

Эти подмножества ключей также будут меняться периодически.

Мне сложно определить, есть ли у NServiceBus парадигма на месте, чтобы справиться с этим?

Answer 1

№ Это называется «маршрутизация на основе контента», и это не то, что поддерживает NServiceBus. Хотя NSB поддерживает некоторые брокерские транспорты (например, SQL Server, RabbitMQ), он логически разработан как распределенная модель. Чтобы сделать маршрутизацию на основе контента, необходим центральный центр, который контролирует доставку сообщений на основе контента.

Уди Дахан имеет сообщение, объясняющее, почему NSB не поддерживает эту функцию here.

Answer 2

Способ подхода к этому состоит в том, чтобы подумать о том, какие существенные различия существуют в сообщении пользователя, где пользовательский ключ равен 111 или 222, и сообщение пользователя, где это не так.

Вероятный вывод состоит в том, что они фактически представляют собой разные вещи в вашем бизнес-процессе, поскольку каждый будет потребляться с другим эффектом, чем другой. Это сигнал, что вам действительно нужно создавать новые типы сообщений, чтобы различать эти различные бизнес-кейсы.

Скажет, например, у вас есть следующее сообщение о событии:

public interface IUserAddedInformation 
{ 
    Guid UserKey { get; set; } 
    InformationType informationType { get; set; } 
} 

public enum InformationType 
{ 
    Address, 
    CreditCard 
} 

Вы настраиваете абонент для обработки сообщения и обрабатывать изменения. Однако вы скоро поймете, что личные данные, такие как данные адреса и оплаты, такие как данные кредитной карты, очень разные, поэтому вы хотите обрабатывать два экземпляра отдельно. Но как это сделать без маршрутизации на основе поля informationType в сообщении?

public interface IUserAddedCreditCard 
{ 
    Guid UserKey { get; set; } 
} 

public interface IUserAddedAddress 
{ 
    Guid UserKey { get; set; } 
} 

Теперь вы можете создавать отдельные обработчики для обоих событий. Возможно, вы сможете пройти аналогичный процесс в приведенном выше примере, чтобы выяснить, как получить нужное поведение маршрутизации.