When to use autowiring in ColdSpring
Posted by Steve Brownlee on September 15, 2008Sep 15
Autowiring in ColdFusion
Most of you may have heard of autowiring, and many of you may have implemented it in an application by now (most likely with Spring, ColdSpring, or Google Guice).
If you don’t know what autowiring is, or are curious about how to do it, I’ll simply direct you to other people who have adequately explained it (see reference links at bottom of article) rather than doing it myself. This article is about when to use it, not how to use it.
Most people I talk to, or have read articles by, promote autowiring as a positive thing. It offers an effective way to automatically inject instantiated components into other components that require their methods. Who wouldn’t be a fan of that??
Nevertheless, there are gadflies who point out that the overuse of autowiring defeats one of the benefits of your bean definition file: a documentation tool. It is the one place in your application that clearly shows how services depends on each other. I believe this is a valid point, as I often use my definition file as a quick reference to my application’s dependencies.
Autowiring Incidental Dependencies
I prefer to use the autowiring feature for beans that are not business logic:
- Datasources
- Configuration settings
- Resource libraries (e.g. Transfer ORM)
- Transfer/Value objects
For example, several of my apps are written using Model-Glue, and I define beans to pass the application’s datasource, and transfer service:
<bean id="datasource" factory-bean="transfer" factory-method="getDatasource" />
<bean id="transferService" factory-bean="transfer" factory-method="getTransfer" />
Most of my beans require one, or both, of these services, and I’m reluctant to pass them in as constructor arguments since I consider them incidental dependencies, rather than logical dependencies. I see no benefit in having these clutter up my definition file since they offer no help to me, or anyone else, when determining if the Facility component requires the use of the Organization_Demographics component or not.
Instead of having dozens of these definitions filling up my definition file:
<bean id="DrugMapping" class="coldspring.aop.framework.ProxyFactoryBean">
<property name="target">
<bean class="&appCFCMapping;.model.request.item.drug.DetailService">
<constructor-arg name="transfer">
<bean factory-bean="transfer" factory-method="getTransfer" />
</constructor-arg>
<constructor-arg name="Offering">
<ref bean="Offering" />
</constructor-arg>
<constructor-arg name="Party">
<ref bean="Party" />
</constructor-arg>
<constructor-arg name="DetailGateway">
<bean class="&appCFCMapping;.model.request.item.drug.DetailGateway">
<constructor-arg name="transfer">
<bean factory-bean="transfer" factory-method="getTransfer" />
</constructor-arg>
<constructor-arg name="datasource">
<bean factory-bean="transfer" factory-method="getDatasource" />
</constructor-arg>
</bean>
</constructor-arg>
<constructor-arg name="datasource">
<bean factory-bean="transfer" factory-method="getDatasource" />
</constructor-arg>
</bean>
</property>
<property name="interceptorNames">
<list>
<value>exceptionLoggingAdvisor</value>
</list>
</property>
</bean>
Instead I enjoy looking at a definition file that shows me how I’m wiring my application together.
<bean id="DrugMapping" class="coldspring.aop.framework.ProxyFactoryBean" autowire="byName">
<property name="target">
<bean class="&appCFCMapping;.model.request.item.drug.DetailService">
<constructor-arg name="Offering">
<ref bean="Offering" />
</constructor-arg>
<constructor-arg name="Party">
<ref bean="Party" />
</constructor-arg>
<constructor-arg name="DetailGateway">
<bean class="&appCFCMapping;.model.request.item.drug.DetailGateway" autowire="byName" />
</constructor-arg>
</bean>
</property>
<property name="interceptorNames">
<list>
<value>exceptionLoggingAdvisor</value>
</list>
</property>
</bean>
Reference Links
Joe Rinehart on autowiring
Nando demystifies autowiring
Download a small, sample app that provides autowiring code


You could also do this with parent beans and gain the same benefits without losing the explicit declaration of the dependencies:
http://www.coldspringframework.org/coldspring/examples/quickstart/index.cfm?page=parentbeans
Brian: Nice!!! Thanks for pointing me to the docs.