Haha -- oh yeah, I read over this and I'm pretty sure I made that opening line clear as mud :)
"None of my CFCs actually use any of their dependencies within the CFC." Correction: My CFC's do use their dependencies (obviously, or they wouldn't need to be there), but not globally. None of the dependencies are used *everywhere* is what I was trying to get across. They're scattered throughout various functions. Jonathon -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathon Stierman Sent: Tuesday, June 19, 2007 11:58 AM To: [email protected] Subject: [coldspring-dev] newbie question! None of my CFCs actually use any of their dependencies within the CFC. All the dependencies are scattered throughout the various functions: Domains.cfc Variables.datasource; // datasource Variables.typesCFC; // non-circular dependent CFC Variables.emailsCFC; // circular dependent CFC function init() /* no dependencies */ function setEmailsCFC() /* no dependencies */ function verifyDomain() /* dependent on typesCFC */ function getAllDomains() /* dependent on Variables.datasource */ function addDomain() /* dependent on Variables.datasource */ function editDomain() /* dependent on Variables.datasource */ function deleteDomain() /* dependent on Variables.datasource, Variables.emailsCFC */ This is where a little bit of my confusion is stemming from. My Domain.cfc as a whole isn't "dependent" on much of anything -- there's not one attribute that is required for every single function in Domain.cfc. It seemed a tad over-kill to be putting references of my DomainEmails.cfc (Variables.emailsCFC) in my component when it's only needed for a single method (deleteDomain). It seemed the lesser of two evils though, since I don't want to be passing an instance of DomainEmails into my deleteDomain() function -- wouldn't that make every thing that's dependent on Domains also dependent on Domain Emails? Meaning I'd be injecting DomainEmails into yet more objects. Not my desired situation. I'm liking setter-injection. The init-method tag seems to be just what I'm looking for -- an extension of the constructor that will let me solve my circular-dependency problem. Jonathon ________________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Peter J. Farrell Sent: Tuesday, June 19, 2007 11:36 AM To: [email protected] Subject: [coldspring-dev] newbie question! Peter Bell said the following on 6/19/2007 10:36 AM: No golden rule. Two general schools of thought: Use constructor wherever you can and only use setter injection when you have circular dependencies. The idea is that constructors should define the contract for creating the bean so you should put everything there unless you are unable to because of circular dependencies. Other is use setter for everything (unless you need to call methods in the bean in the init and therefore have to have it in the constructor). Principle is that if you dont have a use case where you need to call methods in init on injected beans, you can just use setter for everything so you dont have to worry about which to use or refactor if circular dependencies arise. Actually, I believe the best practice is for CS (at least in my mind after talking to Chris, Dave and Kurt) to favor setter injection versus constructor-arg injection. Unless you need something in the init() method of the bean you are wiring up. However, you can usually get away with using the init-method attribute option. <bean name="someService" id="dot.path.to.someService" init-method="setup"> <property name="someOtherService"><ref bean="someOtherService"/></bean> <property name="thatService"><ref bean=""thatService"/></bean> </bean> Order of operations: 1. Create someService 2. Call init() with any constructor args (must resolve dependencies first) 3. Wiring in properties 4. Call init-method (yes, it's a misleading name, but it follows the Spring DTD here). In my architecture, we call this the setup() method. As you can see, any setup stuff that heavily relies on other beans can be done in the setup method. .Peter
