Блог

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

Моя ситуация совершенно особенная. Допустим, у меня есть две таблицы: Билет и Участник с отношениями 1:n. Я использую React, .NET 5, ядро Entity Framework и rest для общения. Но особенность в том, что я не явным образом настраиваю его связь через ядро Entity Framework. Это означает, что в базе данных у члена таблицы все еще есть ссылка на внешний ключ(идентификатор билета) на билет. Но не отображается в коде.

Проблема возникает, когда я пытаюсь создать билет. Потому что Билет всегда должен содержать список Участников. В настоящее время у меня есть два способа сделать это.

1. Определите маршрут, такой как api/билеты, и отправьте объект, содержащий все данные, обратно по этому маршруту, который мне нужно создать. Пример: ticket:{id: 1, .... , members: []} .
2. Определите 2 отдельных api/билета маршрута и api/участников и отправьте отдельные данные на каждый маршрут для создания.

Первый подход заключается в том, чтобы убедиться, что данные всегда успешно или неудачно работают в одно и то же время(для этого я использую транзакцию в бэкэнде). Но, похоже, это не лучшая практика с отдыхом. Второй подход заключается в том, чтобы следовать лучшей практике. Но что произойдет, если одно из этих действий окажется неудачным? Я не могу отступить, как в первый раз.

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

Соотношение между участником и билетом может быть 1:n.

У 1 участника может быть n билетов.

1 билет может принадлежать 1 участнику

итак, класс участника содержит список билетов. Для rest вы можете определить конечную точку, например api/tickets/create, в которой объект-участник содержит билеты и информацию о пользователе. вы должны обрабатывать логику покупки билетов в своем rest api, и разделение этой операции на два api не является лучшей практикой и только усложняет вашу бизнес-логику.