Внесение изменений в классы Nsb Message и SagaData

Question

И наши классы Message, и наши классы SagaData содержат свойства, которые определены в нашем проекте модели централизованного решения. Сейчас мы находимся в процессе рефакторинга нашего решения, так что у нас будет конкретный проект, в котором будут определены свойства наших классов NServiceBus. Мы делаем это, чтобы надеяться отделить Nsb-слой от остальной части приложения и избежать ненужного загрязнения наших Nsb-классов при изменении проекта Model решения.

Nsb-специфическая модель (Nsb.Model)Проект будет тесно отражать центральный проект Model, а AutoMapper позаботится о отображении наших объектов из Nsb.Model <-> Model.

Я думаю, нам не нужно слишком беспокоиться о рефакторинге наших классов Message,так как должно быть достаточно безопасно просто развернуть это изменение, когда нет сообщений в полете (у нас будет много возможностей сделать это)

Меня больше беспокоит наши классы Saga и SagaData. Всегда будет какая-то работа Saga (в основном бездействующая в ожидании времени ожидания), и я беспокоюсь, что могут возникнуть проблемы с уже запущенной Saga, когда мы вносим изменения в класс SagaData. Изменения в классах SagaData в основном ссылаются на новую сборку (Nsb.Model), которая имеет все те же классы, что и старая сборка (модель). Один из классов был переименован в новой сборке, за исключением того, что все они идентичны старым.

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

Любое понимание очень ценится. Спасибо

Answer 1

NServiceBus использует NHibernate для создания схем, представляющих класс SagaData. Вы можете либо полагаться на NHibernate, пытаясь изменить текущую схему, либо самостоятельно писать сценарии миграции .

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

Изменение сложного объекта в коллекции вызовет трудности. Лучший способ узнать, работает ли это для вашего проекта, - это на самом деле выполнить обновление и проверку во время разработки и в тестовой среде.

Я подозреваю, что вы уже какое-то время работаете, в противном случае SQL Persister (который нене использует OR / M) использует сериализованные объекты JSON для хранения данных в одном столбце, и он зависит от гибкости сериализатора при переходе от версии к версии. Наши клиенты добились гораздо лучших результатов, чем с NHibernate.

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