0

At work one of my colleague asked to me to change the way a Spring StoredProcedure subclass class was initialised from injecting the parameters with Dependency Injection mechanism (Constructor Injection) to a "more straight forward and simple way".

The actual code with DI initialization looks like :

<constructor-arg><ref bean="datasource"/></constructor-arg>
<constructor-arg value="STOREDPR"></constructor-arg>  
<constructor-arg>
<list>
                <bean parent="SQL.TIMESTAMP.IN">
                    <constructor-arg type="java.lang.String" value="parameter1" />
                </bean>
                <bean parent="SQL.TIMESTAMP.INOUT">
                    <constructor-arg type="java.lang.String" value="parameter2" />
                </bean>
                <bean parent="SQL.NUMERIC.IN">
                    <constructor-arg type="java.lang.String" value="parameter3" />
                </bean>
</list>
</constructor-arg>

SubClass of StoredProcedure injected constructor :

public AStoreProcedure(DataSource datasource, String procedureName, List<SqlParameter> params) {
    super(datasource, procedureName);

    for(SqlParameter p : params) 
        declareParameter(p);

    compile();
}

In my opinion construction of a StoredProcedure with DI is not a bad idea since you can change the StoreProcedure signature(declared parameters) without having to change the code of your application, but just changing the XML ...

Do you think removing DI mechanism in this case make sense ? What could be a good alternative ?

  • "just changing the XML" -- I have found it much easier to modify the Java code. At least the compiler provides some verification that my changes have a chance to work. "Just changing the XML" is much less likely to work the first time. – kevin cline Jan 5 '16 at 6:21
1

There is no way to eliminate possible run-time disagreements between your database and your Java code. The best you can do is ro make your Java code depend only on parths of the schema that are necessary for your business logic, and run integration tests before deploying to production.

0

You can do dependency injection with Java configuration. I is more and more being adapted and preferred.

You can do something like this to register your bean:

  @Bean
  public StoredProcedure storedProcedure(DataSource dataSource) {
    StoredProcedure storedProcedure = new GenericStoredProcedure();
    storedProcedure.setDataSource(dataSource);
    SqlParameter param1 = new SqlParameter("parameter1", Types.VARCHAR);
    storedProcedure.declareParameter(param1);
    //..
    storedProcedure.compile();
    return storedProcedure;
  }
  • Why do you think that this is better approach than having in XML in this case ? – aleroot Sep 6 '15 at 18:30
  • Fact that Java configuration is preferred is reflected in the Spring Guides (spring.io/guides). All are in Java configs. Spring team officially still supports XMLs, but very few new features are done that way. Good example is Spring Boot. I can't think of single Spring Boot feature in XML. Java configs are future and not only in Spring world. – luboskrnac Sep 6 '15 at 18:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.