Обновить
1
Дима@hhdevr

Пользователь

Отправить сообщение

всё, включая загрузку данных

Вы имеете ввиду SQL вызов непосредственно из JRXML файла? Если да, то я вижу здесь 3 проблемы:

  1. сам запрос становится статичным и неизменяемым - для выполнения например дополнительной сортировки или фильтрации необходимо менять весь JRXML файл (либо держать его разные версии для разных видов запросов)

  2. любая миграция схемы базы данных порождает риски несоответствия полей (или их типов) с филдами JRXML

  3. нарушение принципов Separation of Concerns и Single Responsibility

Дополнительно - нужно вручную вписывать все поля ожидаемого из БД ответа и их типы в JRXML - не самая приятная часть работы:

<jasperReport ...>
    <queryString>
        <![CDATA[
            SELECT id, name, salary
            FROM employees
            WHERE department = $P{departmentName}
        ]]>
    </queryString>

    <parameter name="departmentName" class="java.lang.String"/>

    <field name="id" class="java.lang.Integer"/>
    <field name="name" class="java.lang.String"/>
    <field name="salary" class="java.math.BigDecimal"/>
</jasperReport>

Поэтому библиотека реализует в сущности подход аналогичный MVC - данные и модели между слоями не смешаны, что обеспечивает гибкость разработки, а JRXML отвечает только за репрезентацию данных (как фронтенд) и может потреблять любым способом отфильтрованные отсортированные и скалькулированные данные (на тот случай если вы передаете не просто данные намапленные с entity но некую агрегацию их)

нужно ещё использовать обёртку, которая данные вытаскивает

Аннотационный процессор вытаскивает их на этапе компиляции поэтому разработчик получает в /target готовый JRXML в котором все данные предсталены в нужном виде и с точной типизацией.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность

Специализация

Бэкенд разработчик
Ведущий
Java
Spring Boot
Kubernetes