Design: Spring Integration jdbc best practice -

after using spring integration in project, observation use jdbc adapter or gateway @ start or end of flow. if use them in middle of flow become verbose , complex.

for example:

<jdbc:outbound-gateway      query="select * foo         c1=:headers[c1] ,         c2=:headers[c2] ,         c3=:headers[c3] ,         c4=:headers[c4]"     row-mapper="foomapper" data-source="mydatasource" max-rows-per-poll="100000" />  <int:service-activator ref="serviceactivator" method="processfoo" /> 

in above <jdbc:outbound-gateway>, need pass placeholders (c1, c2, c3, c4) in header of message. need , forth in java code , xml file change in condition or when there many clauses.

it error prone. example, if misspelled :headers[c1] :headers[d1] not throw exception , replace :headers[d1] null.

if query not return row throw exception default. so, have use requires-reply="false" change default behaviour.

if want proceed when query not return value have add advice gateway, shown below:

<jdbc:outbound-gateway ... >     <jdbc:request-handler-advice-chain>         <bean class="com.service.nullreplyadvice" />     </jdbc:request-handler-advice-chain> </jdbc:outbound-gateway> 

please correct me if there flaws in understanding of concept.

we need , forth in java code , xml file change in condition or when there many clauses.

it's true raw java code around jdbc: if change model you, of course, should change select, because string. , that's why there lot of work make type-safe - orm, querydsl, spring-data etc.

if misspelled :headers[c1] :headers[d1] not throw exception , replace :headers[d1] null.

that's because headers map , it's truth null, if there no such key in map. overcome typo issue can use pojo payload getters, or custom header, , again - pojo getters. in case end exception there no such property against object. although you'll see issue @ runtime, not on compile. , again same hashtable - @ runtime.

so, have use requires-reply="false" change default behaviour.

you should understand @ design time: allow or not return nothing component.

the last idea good. wouldn't mind share nullreplyadvice? achieve same <filter> before jdbc gateway: determine if there fetch count(*) query. there can lead flow different logic, rather direct flow, when select returns rows.

update

when want use model object keep business-specific values within message, it's enough put object header:

public class foo {     private string foo1;     private string foo2;     public string getfoo1() {       return foo1;    }     public string getfoo2() {       return foo2;    }  }  ...  messagebuilder.withpayload(payload).setheader("foo", foo).build();  ...  <jdbc:outbound-gateway      query="select * foo         c1=:headers[foo].foo1 ,         c1=:headers[foo].foo2"/>