Нужно ли разделять контроллер с несколькими конечными точками, которые представляют операции CRUD компонентов более сложного объекта?

Question

В данный момент у меня есть объект (назовем его ComplexObj), состоящий из 10 различных объектов, и мне нужно создать контроллер REST или несколько для обработки операций CRUD для ComplexObj, а также для его 10 различных объектов по отдельности.

Я занимался исследованиями, и люди говорят о том, чтобы разделить их, если у них совершенно другая бизнес-логика. В этом случае объекты ComplexObj имеют немного иную бизнес-логику, но, поскольку они равны 10, я чувствую, что create 10 (контроллер на объект) + 1 (контроллер для ComplexObj) будет слишком большим.

public class ComplexObj {
    private ObjA objA;
    private ObjB objB;
    private ObjC objC;
    private ObjD objD;
    private ObjE objE;
    private ObjF objF;
    private ObjG objG;
    private ObjH objH;
    private ObjI objI;
}

Один из вариантов использования, который у меня есть, - это ComplexObj, если он не существует, когда конечная точка сохраняет ObjA.

Answer 1

Дизайн конечных точек REST зависит от предметной области. Не существует жесткого и быстрого правила, чтобы сделать одну или несколько конечных точек. Это все о том, как вы разрабатываете для бесперебойной работы вашего приложения. Каждая конечная точка REST с контроллером должна быть очень согласованной. Давайте рассмотрим пример, в котором каждая организация может иметь много отделов, в каждом отделе может быть много сотрудников, у каждого сотрудника будут адреса и так далее. Технически вы можете спроектировать только одну конечную точку REST для решения этой проблемы, но это не будет хорошим дизайном. Прежде всего, у вас есть адрес, который указывает, сколько организаций существует, и одна конечная точка REST должна указывать детали организации с ее идентификаторами. Следующая конечная точка REST должна обращаться к отделам с идентификатором org и так далее. Если вы посмотрите на этот пример, наш объект Organisation будет более сложным, так как он будет иметь отделы, каждый отдел будет иметь Employee в качестве объекта и т. Д.

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

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

Answer 2

Я полагаю, что именно здесь возникает идея создания различных микросервисов. Это зависит от того, как ComplexObj, ObjA, ObjB ... рассматриваются с точки зрения сегрегации бизнеса.

Так что, если ObjA и ObjB - это два разных несвязанных ресурса в бизнес-терминах, необходимо создать два разных микросервиса с разными конечными точками.

Теперь, скажем, ComplexObj - это ресурс, который состоит из ObjA и ObjB, он должен вызывать нисходящие микросервисы ObjA и ObjB для выполнения операций CRUD.