If you look at some of the generated bean definition XML out of the code generator, you can see what it is doing with the dependencies.
The generator creates a {tablename}Service.cfc which is a bean for talking to the DAO and Gateway (you might think of it as a 'data access delegate'). This is the only piece of generated code that your business objects should consume. Hence, the business objects should not actually know anything about the DAO and Gateway, which keeps them decoupled from the persistence implementation - this allows you to sub in some other kind of database access layer without having to modify the business objects, all you have to do is change how your data access delegate works.
In order for the data access delegate to function properly it must have references to instantiated objects from the data persistence layer, being the DAO and Gateway. If you were to instantiate the data access delegate yourself, you would have to supply it with already-instantiated copies of the DAO and Gateway, or you would have to modify the delegate to create these objects itself. Neither of these is an ideal situation, the former because it requires your business object to know more than it should about the persistence layer, and the latter because it requires the service to know the mechanics for instantiating the DAO and Gateway (and presumably, the datasource information would have to be passed in somehow as well). This is where ColdSpring comes into play.
The ColdSpring BeanFactory will handle these kinds of messy dependencies for you, by injecting copies of your DAO and Gateway into the Service during instantiation. You can specify a datasource property that ColdSpring should use, and during the init() method of all the components it will resolve the dependencies for you. This way, none of your business objects have to know too much about layers from which they ought be decoupled.
The other thing you can do is even put simple bean definitions (where there are no dependencies) into your bean definition file, and ask a cached copy of the ColdSpring framework to do a getBean() whenever you would've created one yourself. This further abstracts the mechanism by which objects are created, and allows you to easily wire in dependencies if need be.
HTH,
Eric
On 11/1/06, Dan Vega <[EMAIL PROTECTED]> wrote:
I was wondering if anyone can help point me in the right direction. I have been writing cfc's since you were able to. I have never gotten into any type of design pattern. I am now using the Illudium PU-36 Code Generator to create my DAO's, Gateways, Service Layers, Colspring.xml etc... I am just getting into coldspring as well. I am just wondering if there are any tutorials out there that help explain how coldspring works and how it ties all of my cfc's toegether for each of my components. Any small apps would be great as well.
Thank You
Dan Vega
[EMAIL PROTECTED]
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
