ColdBox using ColdSpring

The more I work in ColdBox the more I want to learn, so pardon my ramblings but yesterday ColdBox and ColdSpring took my fancy. I have never worked with ColdSpring nor any other AOP for CFC's.

So ColdSpring, what's all that about then? To be honest I am still not sure why I would use it. I started by playing around, I wanted to inject my ColdBox DNS setting into my common.cfc (database gateway).

view plain print about
1<beans default-autowire="byName">
2<bean id="coldboxFactory" class="coldbox.system.extras.ColdboxFactory" />
3<bean id="ConfigBean" factory-bean="ColdboxFactory" factory-method="getConfigBean" />
4<bean id="dsnBean" factory-bean="ColdboxFactory" factory-method="getDatasource">
5    <constructor-arg name="alias">
6    <value>DBDetails</value>
7    </constructor-arg>
8</bean>    
9    <bean id="userService" class="model.UserService" />
10    
11    <bean id="userGateway" class="model.common" >
12     <property name="dsnBean">
13 <ref bean="dsnBean" />
14 </property>
15 </bean>
16
17</beans>

I then created a UserService.cfc. The idea I think behind this is that I access the userService.cfc to get to common.cfc (gateway) and common.cfc gets the DNS setting injected.

view plain print about
1<cfcomponent name="User Service">
2
3<cffunction name="init" access="public" returntype="any" hint="Constructor.">
4 <cfreturn this />
5</cffunction>
6
7<cffunction name="getUserGateway" access="public" returntype="any" output="false" hint="Return the UserGateway.">
8 <cfreturn variables.instance['userGateway'] />
9</cffunction>
10
11<cffunction name="setUserGateway" access="public" returntype="void" output="false" hint="Set the UserGateway.">
12 <cfargument name="userGateway" type="any" required="true" hint="UserGateway" />
13 <cfset variables.instance['userGateway'] = arguments.userGateway />
14</cffunction>
15</cfcomponent>
view plain print about
1common.cfc
2<cffunction name="setdsnBean" access="public" returntype="void" output="false" hint="Set the dsnBean.">
3 <cfargument name="dsnBean" type="any" required="true" hint="dsnBean" />
4 <cfset variables.instance['dsnBean'] = arguments.dsnBean />
5</cffunction>

Why is this any better? I could have achieved this all in the init() method without ColdSpring, or I could have extended my CFC, or I could have even created a config CFC and injected that into the common.cfc.

Sorry, If these questions are just ignorant.

Related Blog Entries

Jul24

Post Info

Comments 4

[Add Comment] [Subscribe to Comments]
  1. Henry Ho's Gravatar # Posted By Henry Ho
    24/07/09 19:41

    Why would you want to use a dsnBean at the first place?

    Wouldn't it be better to inject the dsn (string) directly into UserGateway?

    Read this: http://www.coldspringframework.org/coldspring/exam...

  1. Glyn Jackson's Gravatar # Posted By Glyn Jackson
    25/07/09 16:25

    I see what you mean in the coldspring.xml it's creating a bean then injecting that into common.cfc, this was taken from the the ColdBox examples. I am assuming there is a reason for this.

  1. Henry Ho's Gravatar # Posted By Henry Ho
    25/07/09 16:32

    I would not couple my model to Coldbox through use of dsnBean. Just inject the dsn into your DAO/Gateway through constructor-arg is generally better.

  1. Peter Bell's Gravatar # Posted By Peter Bell
    29/07/09 18:53

    Why use ColdSpring? Mainly to decouple your CFC's for testing (it also provides a single place to put a lot of config settings, but that is a secondary benefit).

    Let's say you have a UserService that requires a UserValidator object. You could just createObject() within UserService.init() or call some kind of factory (application.beanFactory.getBean("UserValidator").

    In the first case, as the complexity of the config settings for UserValidator grows, you need to maintain that in your UserService code (all the properties you need to pass to the init() constructor, etc).

    In the second case, you've put all the knowledge about creating beans into one factory to make it easy to maintain, but you're still calling the application scope, so there is no easy way to mock/stub out the UserValidator implementation in your unit tests for the UserService.

    If all this sounds like double dutch, you may not need a DI engine like ColdSpring or LightWire right now. Once you notice that you're having problems writing unit tests for your objects or with the complexity of the initialization of your cfc's all over the place, time to come back and have another look!

    Peter

[Add Comment]