Ben,
I think the best way to describe it is that there are two forms of
dependency-injection: constructor-argument-based and
setter-method-based. Inversion of Control is what you get when you do
either.
The second part is trickier. This is something that often trips up
people using [Cold]Spring[.NET] - it's not very typical to let the
BeanFactory create your "domain objects", like the bean with a
validate() method that you mentioned. The reason is that these objects
are often created by existing logic/processes, for instance within a DAO
or ORM Tool like Arf! or Reactor, or from the controller-layer of your
application as a result of processing user input.
One of the core tenets of Spring is that it is non-invasive, meaning
your code doesn't know it's there. If you used Spring to create your
domain objects, this would no longer be true (because the code that used
to say createObject(...,"someSimpleBean") would know have to obtain a
reference to ColdSpring and call getBean('') ).
With that being said, some gurus (like Martin Fowler) have said that
dependency-injection is needed within domain objects and the lack of it
ends up with an "anemic domain model", which could be good or bad (I'm
on a diet these days so I see it as a good thing :) It's something that
they are going to address in Spring 2.0, but if you are interested you
should read this thread on TSS, there's some valuable insight in there:
http://theserverside.com/news/thread.tss?thread_id=38047
The example from the article demonstrates injecting a DAO into a domain
object, which is probably a bad example of what you'd use it for. In
fact your validation example is much more "real world", where you'd have
a validator utility that you'd like to inject into all domain objects
that need it. Regardless, read the responses on TSS to gain some insight
as to where the chips fall on this.
-Dave Ross
>>> [EMAIL PROTECTED] 12/16/05 8:12 AM >>>
Ok, so I accept that I am like the leastest smartest person on CFC Dev,
so
thanks for letting me mooch all of your super smarts....
I read the ColdSpring documentation this morning and I like where it is
going. But just to be clear... passing in objects via constructors or
using
setter injection... those are both forms of IoC right?
Follow up: Let's say that I have an entity bean that has a Validat()
method
and that that method returns, lets say, class
EntityBeanValidationCollection
which is just a collection of error messages implementing
InterfaceCollection. Should I let the bean take care of creating the
collection? Or is this something that I would want to pass in via the
constructor:
<cffunction name="Init" returntype="PublicationBean">
<cfargument name="UDFLib" type="UDFLib" required="yes" hint="UDF
libraries" />
<cfargument name="Errors" type="EntityBeanValidationCollection"
required="yes" />
<cfset VARIABLES.UDFLib = ARGUMENTS.UDFLib />
<cfset VARIABLES.Errors = ARGUMENTS.Errors />
.... More code here ....
<cfreturn THIS />
</cffunction>
Thanks CF'ers!
......................
Ben Nadel
Web Developer
Nylon Technology
6 West 14th Street
New York, NY 10011
212.691.1134
212.691.3477 fax
www.nylontechnology.com
"Vote for Pedro"
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of
the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
-----------------------------------------
CONFIDENTIALITY NOTICE: This email and any attachments may contain
confidential information that is protected by law and is for the
sole use of the individuals or entities to which it is addressed.
If you are not the intended recipient, please notify the sender by
replying to this email and destroying all copies of the
communication and attachments. Further use, disclosure, copying,
distribution of, or reliance upon the contents of this email and
attachments is strictly prohibited. To contact Albany Medical
Center, or for a copy of our privacy practices, please visit us on
the Internet at www.amc.edu.
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
