Лучший способ координировать атомарные транзакции между различными бизнес-сервисами в .NET Core / EF Core 2.1?

Question

Допустим, у вас есть служба UsersService, служба TenantsService и служба TenantUserRolesService.

Каждая из этих служб имеет метод «создания» для создания своей сущности и имеет одинаковую внедренную зависимость DbContext, за исключением UsersService, в который введен класс Identity UserManager.

Ваша цель - предоставить конечную точку API, которая позволяет регистрировать нового арендатора, который создает сущность User, Tenant и TenantUserRole. TenantUserRole создается последним и является ассоциативной сущностью с внешними ключами для вновь созданного пользователя, вновь созданного арендатора и роли «Владелец».

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

Я смотрел на: https://docs.microsoft.com/en-us/ef/core/saving/transactions,, но я не могу понять, есть ли способ использовать эти методы между различными классами обслуживания.

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

Я надеюсь, что есть кто-то, кто немного более осведомлен в этом вопросе, который может направить меня в правильном направлении.

Спасибо

Answer 1

Предполагая, что вы создаете сервисы RESTFul, имейте в виду, что сервисы REST по определению не имеют состояния и не должны участвовать в транзакционной границе, охватывающей несколько сервисов.

Ваши услуги выглядят как наноуслуги. Ваши данные сильно коррелированы, поэтому то, как вы сломали свои услуги, выглядит очень искусственно. Что если вашему приложению необходимо отобразить список всех арендаторов? Рассматривали ли вы последствия для производительности и сложность реализации HATEOUS?

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

Пожалуйста, не поддавайтесь искушению заключить ваш вызов в 3 API в одну транзакцию. Это не только полностью анти-REST, но, скорее всего, вам не нужны 3 API, если они все используют одну и ту же базу данных.