NServiceBus Ненавязчивые соглашения Определение команд Как несколько раз

Question

Кажется, что я не могу определить соглашения команд/событий более одного раза. Каждое зарегистрированное соглашение отменяет предыдущие.

Это работает:

configuration.Conventions() 
      .DefiningCommandsAs(
       type => type.FullName == "MyProject1.CommandA" || type.FullName == "MyProject2.CommandB"); 

Но это не делает:

 configuration.Conventions() 
      .DefiningCommandsAs(
       type => type.FullName == "MyProject1.CommandA"); 

     configuration.Conventions() 
      .DefiningCommandsAs(
       type => type.FullName == "MyProject2.CommandB"); 

Зачем мне это нужно:

Я разрабатываю пакет, который когда-то ссылка в проекте NSB будет выполнять периодические действия (отправлять сообщения). Он должен определить собственные соглашения команд в INeedInitialization, которые будут отобраны во время сканирования сборки. Я не хочу, чтобы пользователь пакета знал, что ему нужно регистрировать соглашения пакета. Однако хост-проект должен регистрировать собственные соглашения для команд. Поэтому мне кажется, что в данный момент мне нужно либо прибегнуть к интерфейсам Marker (чего я не хочу делать, есть веская причина, почему был введен ненавязчивый режим), либо придумать соглашения, как и все команды, которые должны находиться в * .Commands. * пространство имен, которое мне тоже не нравится.

Таким образом, вопросы заключаются в том, как сделать регистрацию пакетов собственными соглашениями ненавязчиво и прозрачно для Хоста.

Редактировать

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

Answer 1

Условные обозначения сообщений, не поддерживающие несколько вызовов, определенно по дизайну. Это делается для того, чтобы не допускать множественных мнений о том, что такое сообщение. Наличие у них аддитивности подразумевает, что у кого-то может быть мнение.

Таким образом, этот шаблон призван обеспечить трение против этого, чтобы вы согласились с одним определением того, что Команда означает внутри всей системы. В принципе, SOA Tenet # 4: совместимость службы основана на политике. Много раз это «пространство имен, заканчивающееся на .Commands» pattern; Я использовал его лично, и он работает хорошо.

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

Если вам абсолютно необходимо сделать что-то другое, ваша идея в вашем Редактировании создания своего рода MessageRegistry singleton и наличия делегата конвенции до MessageRegistry.IsCommand(Type) совершенно применима. В V5 ничего не будет выполнено до тех пор, пока автобус не запустится до тех пор, пока MessageRegistry будет заполнен до начала шины (что также может быть выполнено с INeedInitialization), тогда все должно работать отлично.

Если вы попадёте по этому маршруту, я бы посоветовал вам пройти весь путь, и ваш сингл реестра будет отвечать за другие метаданные, такие как TimeToBeReceived, DataBus, WireEncryptedString, Express и любые другие метаданные сообщений на основе атрибутов.