MassTransit: модели и практики с контрактными классами - PullRequest
1 голос
/ 13 марта 2019
  1. Общий совет для архитектуры микросервисов - избегать разделения классов сообщений между микросервисами. MassTransit в значительной степени полагается на информацию о типах .NET при отправке / получении сообщений, поэтому, если вы объявите два одинаковых типа в двух разных микросервисах, он не будет работать.

Этого можно добиться с помощью некоторой дополнительной конфигурации?

  1. Типичным шаблоном в MassTransit является объявление интерфейсов сообщений вместо POCO, а затем передача анонимных объектов в методы Publish / Send. В этом случае, если я что-то изменю в своем интерфейсе сообщений (например, переименую свойство), я не получу ошибку во время компиляции.

Почему это рекомендуется? Как бороться с хрупкостью анонимных объектов?

Спасибо!

1 Ответ

4 голосов
/ 13 марта 2019

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

В документации четко указано:

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

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

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

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

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

Последнее, что касается совместного использования, - это то, что мы отошли от практики обмена контрактами сообщений с использованием пакетов nuget. Хотя это выглядит привлекательно и безопасно, оно создает некоторые препятствия в нашей повседневной работе. Мы предпочитаем копировать классы сообщений (или интерфейсы) поверх или использовать исходные пакеты. Если команды следуют хорошим практикам, таким как управление версиями и слабая схема, это не создает никаких проблем. Единственное, о чем вам нужно позаботиться, это сохранить пространства имен без изменений.

...