Вы имеете ввиду SQL вызов непосредственно из JRXML файла? Если да, то я вижу здесь 3 проблемы:
сам запрос становится статичным и неизменяемым - для выполнения например дополнительной сортировки или фильтрации необходимо менять весь JRXML файл (либо держать его разные версии для разных видов запросов)
любая миграция схемы базы данных порождает риски несоответствия полей (или их типов) с филдами JRXML
нарушение принципов 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 в котором все данные предсталены в нужном виде и с точной типизацией.
Вы имеете ввиду SQL вызов непосредственно из JRXML файла? Если да, то я вижу здесь 3 проблемы:
сам запрос становится статичным и неизменяемым - для выполнения например дополнительной сортировки или фильтрации необходимо менять весь JRXML файл (либо держать его разные версии для разных видов запросов)
любая миграция схемы базы данных порождает риски несоответствия полей (или их типов) с филдами JRXML
нарушение принципов Separation of Concerns и Single Responsibility
Дополнительно - нужно вручную вписывать все поля ожидаемого из БД ответа и их типы в JRXML - не самая приятная часть работы:
Поэтому библиотека реализует в сущности подход аналогичный MVC - данные и модели между слоями не смешаны, что обеспечивает гибкость разработки, а JRXML отвечает только за репрезентацию данных (как фронтенд) и может потреблять любым способом отфильтрованные отсортированные и скалькулированные данные (на тот случай если вы передаете не просто данные намапленные с entity но некую агрегацию их)
Аннотационный процессор вытаскивает их на этапе компиляции поэтому разработчик получает в /target готовый JRXML в котором все данные предсталены в нужном виде и с точной типизацией.