Обработка дочерних данных с помощью микросервисов

Question

Я пытаюсь выяснить, как лучше организовать свой код в новых проектах.Я использую микросервисный подход с .NET Core API и Angular UI.

Мне нужно обернуться вокруг следующего примера:

У меня есть объект родительского уровня, Invoices.В моей базе данных есть таблица Invoices, и я создаю сервис Invoices в API, который будет обрабатывать CRUD.

Каждый счет-фактура имеет отношение один-ко-многим с InvoiceDetails, что обеспечивает более глубокий уровеньинформация о счете-фактуре.

Я планирую сохранить InvoiceDetails CRUD в том же InvoicesService, который указан выше, поскольку в моей голове все сводится к этому сервису.

Это кажется достаточно простым, но я разрываюсь на сторону пользовательского интерфейса вещей.Когда я создаю свой Счет-фактуру, мне нужно также создать InvoiceDetails.Должен ли я сделать один вызов API для создания счета-фактуры, затем по возвращении сделать другой для создания InvoiceDetails, или все это должно быть обработано за один вызов?

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

Answer 1

С точки зрения управляемой доменом разработки это будет зависеть от того, что представляет собой объект / агрегат в вашем бизнес-домене. В настоящее время InvoiceDetails похожи на объект Value, который не требует собственной идентичности, что говорит о том, что ему не нужны собственные веб-API CRUD.

Один из способов взглянуть на этот вопрос - спросить себя, имеет ли смысл, чтобы InvoiceDetails существовал сам по себе. Имеет ли смысл создавать InvoiceDetails без привязки к какому-либо счету? Если да, то, вероятно, целесообразно иметь отдельную конечную точку API для управления ресурсом InvoiceDetails. Если нет, то каковы основания для создания другой конечной точки для InvoiceDetails?

Answer 2

Я думаю, что ваш API должен иметь конечную точку для создания счета-фактуры, содержащего список объектов InvoiceDetails. В то же время должна быть доступная конечная точка для создания одного объекта InvoiceDetail в вашем API. Think Rest API в этом случае и не очень тесно связан с потребностями одного клиентского приложения angular / реагировать / vue и т. Д.

Это обеспечит гибкость вашего API в случае, если вам понадобится пользовательский интерфейс для добавления дополнительных InvoiceDetails к существующему Invoice или новому полному объекту Invoice со всеми объектами InvoiceDetails.

Какую из этих конечных точек вы используете, должно определяться пользовательским интерфейсом или любым другим клиентом. Например, создание нового Invoice в пользовательском интерфейсе. Я бы хотел создать конечную точку Invoice со списком InvoiceDetails. Добавление InvoiceDetails к существующему Invoice Я буду использовать конечную точку для добавления объекта InvoiceDetails.

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

СЕЙЧАС КАК ОБРАЩАТЬСЯ С API ИЗ UI (ОДИН ИЛИ НЕСКОЛЬКИХ ВЫЗОВОВ)?

Наличие нескольких вызовов API из пользовательского интерфейса для добавления одного и одного объекта InvoiceDetails при создании счета-фактуры может быть проблемой синхронизации между пользовательским интерфейсом и API. Допустим, вы успешно добавили 7/10, но не остальные 3, потому что что-то пошло не так, тогда вам, возможно, потребуется политика повторных попыток и сохранить состояние, которое было успешным или нет для отображения в пользовательском интерфейсе? Как насчет производительности?

Я бы порекомендовал один вызов API при создании объекта «Счет-фактура», который либо будет успешным, либо неудачным и облегчит управление связью между клиентом пользовательского интерфейса и API.