Сортировка на стороне сервера для вычисляемых полей с нумерацией страниц? - PullRequest
1 голос
/ 17 января 2020

Мы должны отобразить некоторые табличные данные, которые поддерживают разбиение на страницы и сортировку на стороне сервера. Это стек React, JAVA, SQL. При разработке REST API мы согласились вернуть составной объект, представляющий каждую строку таблицы. Этот объект создан в результате сложного SQL с большим количеством бизнес-логик c. Объект состоит из нескольких объектов, каждый из которых содержит множество полей. Идея заключается в том, чтобы вернуть универсальный c объект, чтобы нам не нужно было создавать спецификации запроса c DTO.

Однако нам просто нужно использовать несколько полей из этого объекта. Несколько столбцов, отображаемых в пользовательском интерфейсе, рассчитываются на основе нескольких полей в этом объекте. Реальная проблема заключается в том, что нам нужно отсортировать эти вычисляемые поля на стороне сервера, потому что мы просто выбираем записи, которые должны отображаться на странице. У нас возникает соблазн реорганизовать ответ в соответствии со столбцами пользовательского интерфейса, выполнив вычисления на стороне сервера, поскольку мы столкнемся с многочисленными проблемами DTO. Как это может быть достигнуто наилучшим образом? Есть ли лучшие практики для этого? Я не мог найти много на inte rnet.

Ответы [ 2 ]

0 голосов
/ 29 января 2020

Что вы используете для сериализации ответа на JSON?

Если вы используете Джексона, я бы рекомендовал использовать JSON Views, чтобы избежать нескольких DTO. Он позволяет вам указать, какие поля вы хотите сериализовать при каких обстоятельствах (так диктуется контроллером большую часть времени) и довольно прост в использовании.

Вот руководство по его использованию: https://www.baeldung.com/jackson-json-view-annotation

И пример того, как я его использую (например, с классом вложений):

Это модель, в которой я определяю, какой атрибут будет включен в какое представление :

public class Attachment {

    @JsonView({
        Attachment.Views.Show.class, Attachment.Views.List.class
    })
    private Long id;

    @JsonView({
        Attachment.Views.Show.class, Attachment.Views.List.class
    })
    private String originalFilename;

    @JsonView({
        Attachment.Views.Show.class
    })
    private String filepath;

    @JsonView({
        Attachment.Views.Show.class
    })
    private String description;

        public static class Views {
        public static class Show {}
        public static class List {}
        public static class Create {}
        public static class Fill {}
        public static class Edit {}
    }

}

А вот и мой контроллер:

public class AttachmentControllerImpl implements AttachmentController {

    @Inject
    private AttachmentService service;

    private ObjectMapper mapper;

    @Override
    public Response show(Long id) {
        Attachment attachment = service.getById(id);

        String json = mapper.writerWithView(Attachment.Views.Show.class).writeObjectAsString(attachment);
    }

    @Override
    public Response list() {
        List<Attachment> attachments = service.getAll();

        String json = mapper.writerWithView(Attachment.Views.List.class).writeObjectAsString(attachments);
    }

}

На самом деле, здесь не так уж и много чего, он очень прост в использовании.

0 голосов
/ 23 января 2020

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

1) POST запрос к серверу, построить результаты. Вместо того, чтобы возвращать результаты клиенту, он сохраняет результаты в таблице результатов в базе данных вместе с идентификатором ссылки на результаты, который возвращается клиенту в ответ на запрос POST. Эти результаты будут включать рассчитанные поля для сортировки. Сервер может продолжать строить эти результаты в фоновом режиме, после возврата клиенту идентификатора ссылки. Сервер должен ответить ответом 202 Accepted, а не 201 Created.

2) ПОЛУЧИТЬ запрос к серверу для запроса этой таблицы результатов, передав идентификационный номер ссылки. включая поля для сортировки. Если сервер все еще строит список, он может вернуть OK 200, но со строкой JSON, изображающей «здание». В течение этого времени клиент может показывать анимацию таймера и будет повторять запрос каждые несколько секунд.

3) Когда таблица окончательно построена, сервер передает обратно разбитые на страницы данные по мере необходимости.

4) После завершения клиент может отправить DELETE со ссылочным идентификатором для очистки до таблицы результатов. Однако должен быть какой-то процесс очистки, который очистит результаты, скажем, старше суток.

Для получения дополнительной информации см. Здесь: https://farazdagi.com/2014/rest-and-long-running-jobs/

также здесь: http://restcookbook.com/Resources/asynchroneous-operations/

...