Я использую подход на основе Spring Boot and Batch annotation. Я читаю данные таблиц с помощью JdbcCursorItemReader и записываю их в таблицы CSV/XML/other и т. д. В зависимости от необходимости.
В качестве лучшей практики весеннего пакета я просто хотел узнать представление о том, как я создал SQL-запрос внутри метода JdbcCursorItemReader. Есть ли какой-нибудь способ избежать конкатенации и наилучшим образом решить эту проблему, как мы это делаем в подходе на основе XML?
Пожалуйста, дайте мне знать, является ли следующий способ написания SQL-запроса лучшим способом?
Аннотационный подход.
@Bean(destroyMethod = "")
public JdbcCursorItemReader<Orders> employeesReader(){
JdbcCursorItemReader<Orders> itemReader = new JdbcCursorItemReader<>();
itemReader.setDataSource(dataSource);
itemReader.setSql("SELECT orderNumber, productName, msrp, priceEach "
+ "FROM products p "
+ "INNER JOIN orderdetails o "
+ "ON p.productcode = o.productcode "
+ "AND p.msrp > o.priceEach "
+ "WHERE p.productcode = ? ");
itemReader.setRowMapper(new OrdersRowMapper());
itemReader.setIgnoreWarnings(true);
return itemReader;
}
Тот же XML может быть создан с использованием подхода на основе XML без операторов конкатенации.
<bean id = "ordersItemReader" class = "org.springframework.batch.item.database.JdbcCursorItemReader" scope = "step" >
<property name = "dataSource" ref = "dataSource" />
<property name = "sql">
<value>
SELECT orderNumber, productName, msrp, priceEach
FROM products p INNER JOIN orderdetails o ON p.productcode = o.productcode
AND p.msrp > o.priceEach
WHERE p.productcode = '#{stepExecutionContext[productcode]}';
</value>
</property>
<property name = "rowMapper">
<bean class = "com.XXXX.mapper.OrdersRowMapper" scope = "step" />
</property>
</bean>
В моем проекте мы используем подход на основе аннотаций и нуждаемся в руководстве по этому поводу.
Как насчет использования Файл свойств XML? Мне также нравится иметь чистые запросы, и особенно приятно иметь их в одном месте.
Просто создайте свой XML с entry под названием orderQuery с этим запросом как key.
Затем вы можете загрузить свойства XML с помощью обычного @PropertySource и вставить их в свой @Configuration @Bean с помощью @Value("${orderQuery}) или Environment#getProperty.
Надеюсь, это поможет!
Вышеупомянутое решение не означает, что запрос настраивается, и вы все равно можете использовать подход, основанный на аннотациях. Считаете ли вы, что ответ требует дополнительных разъяснений?
Верно. Я ищу передовой опыт и идеальный способ обработки запросов
На мой взгляд, идеального способа не существует. Я пока вижу несколько вариантов. 1) Как и вы, SQL в java-коде прямо у читателя. 2) Храните в нескольких или одном файле .sql. 3) Использование файлов свойств. У каждого подхода есть свои достоинства и недостатки. В вашем случае я использую sql в самом ридере. Причина: а. Мы увидим правильную логику читателя вместо того, чтобы находить ее в ресурсах извне. б. свойства можно легко изменить по ошибке. c. если запросы меняются, у него больше шансов изменить и Java-код.
Лично я считаю, что нужно руководствоваться последовательностью. Если вы используете аннотации в своем проекте, используйте подход на основе аннотаций. В противном случае новичкам может быть сложно понять причину, по которой вы смешиваете xmls и аннотации (возможно, в этом есть какой-то сакральный смысл). С точки зрения удобочитаемости особой разницы не вижу.
P.S. Кстати, я предпочитаю добавлять аннотацию @StepScope к методу вместо того, чтобы помещать (destroyMethod = "")
Спасибо за PS. Мы говорим только о том, как использовать SQL-запрос в самом методе или настроенном в файле свойств. Фрагмент XML показан, потому что он не использует конкатенацию и не создает ненужный объект Spring, который происходит через подход на основе аннотации?
Пожалуйста, забудьте о конкатенации строк. Во-первых, в данном случае это не имеет значения, так как дырочная строка будет объединена во время компиляции (см. stackoverflow.com/questions/11989261/…). Даже в каком-то другом случае, если строка создается путем конкатенации во время выполнения, вы не должны это учитывать, поскольку это очень «дешевая» операция. Производительность конкатенации следует учитывать только в циклах с более чем 10000 операций.
Согласитесь, в основном это обходной путь с точки зрения настройки самого запроса, и если что-то изменится, нам, возможно, не придется создавать код снова. Я считаю, что, по крайней мере, запрос должен быть только в этом месте, а не в файле .properties. Возможно, я использую делегатов, которым может потребоваться написать 5 разных запросов на объединение. Это даст идею для сравнения там само. А пока придерживаемся подхода на основе аннотаций, показанного выше.