Как я могу разделить классы сообщений между приложениями при использовании NServiceBus? - PullRequest
Новая
       11

Как я могу разделить классы сообщений между приложениями при использовании NServiceBus?

4 голосов
/ 29 мая 2009

Итак, у меня есть два отдельных приложения, между которыми я хочу отправлять сообщения. Я использую NServiceBus, но это не должно иметь большого значения. Как отправить сообщение из приложения A в приложение B, чтобы они оба знали об одном и том же контракте?

Итак, приложение A имеет класс SecretMessage ... 

public class SecretMessage : IMessage
{
     public string Title { get; set; }
     public string Body { get; set; }
}

Это объект, который будет сериализован и отправлен по проводам в приложение B.

Теперь, в приложении B, как мне прослушивать сообщения такого типа, а затем иметь возможность десериализовать их в одном классе? Таким образом, я могу использовать данные в том виде, в котором они были отправлены, и это не кошмар обслуживания.

Должно ли приложение B просто иметь копию класса? Должно ли это быть обработано с помощью общих dll классов сообщений, на которые ссылается каждое приложение (надеюсь, нет)? Должны ли они быть воссозданы в каждом приложении как полностью отдельные DTO с одинаковыми свойствами?

Я что-то здесь упускаю?

Ответы [ 2 ]

6 голосов
/ 01 июня 2009

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

На самом деле у вас есть только несколько вариантов, и поэтому зависит от того, какой уровень функциональности и упрочнения типов вы хотите использовать в своих классах сообщений:

  1. Общие библиотеки DLL - выгода, что это может быть код + структура, например. полезные конструкторы, сложные перечислители, отладочные реализации ToString и т. д. Сильное управление версиями. Требуется отдельный проект и дистрибутив для DLL.
  2. Общая схема и генерация кода. Объявите схему для ваших типов и используйте генерацию кода для создания классов. Здесь много разных стратегий - несколько примеров: T4 Templating , Генерация пользовательского кода , Инструменты и библиотеки, такие как CodeSmith или Proto.Bufs, Поиск найдет вас еще больше. Может быть довольно мощным - знать много кодовых магазинов, которые запускают все проекты с помощью быстрого прототипирования с CodeGen от БД до пользовательского интерфейса. Вам все еще нужно распространить схему.
  3. Сериализация сообщения с достаточной точностью для генерации типов с помощью Code DOM. Каждое сообщение несет стоимость переноса метаданных, достаточных для представления всех его экземпляров. например представления обнуляемых полей. Первоначальные затраты на «обнаружение» при создании типов оболочек сообщений также будут существенными.
  4. Сериализует данные в слабой структуре, такой как пары имя / значение, а затем генерирует словарные классы-оболочки. Слабый набор текста - легко продлить '.

Это действительно единственный выбор. ИМХО № 2, то № 1 в этом порядке, как правило, являются наиболее полезными шаблонами.

2 голосов
/ 03 июня 2009

В соответствии с предложением Ювала Лоуи в Программировании компонентов .NET , отдельные чистые интерфейсы в своей собственной общей DLL.

http://arcanecode.com/2007/02/14/more-oop-interfaces-in-c-part-2/

...