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

Question

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

Так приложение А имеет класс SecretMessage ...

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

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

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

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

Я что-то упустил?

Answer 1

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

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

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

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

Answer 2

Как было предложено Juval Lowy in Programming .NET Components, отдельные чистые интерфейсы в их собственной общей DLL.

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