I'm not sure I can agree with what you are stating here:
- Second, doesn't the IoC hide the dependencies in the similar
fashion as
the Service Locator does? And isn't that part of the point of
using IoC?
Joe Rinehart's post about Anemic Domains
How does defining your dependencies in a human readable xml file hide
the dependencies of your domain objects? It seems to me that it does
exactly the opposite!
-And third, any way you look at it someone needs to change
something to make
the new DSN required for DAO #7 to work
Exactly the point of using an IoC container. If you want to tweak a
global setting like a DSN, you make a change in the config file, not
in your serviceLocater object or your factory object, or whatever.
How about having a development conf file and a deployment conf file?
What about the need to change LOTS of config params at once? Maybe
use a serverConfig object with all it's settings defined in the CS
config file, things like DSN names, MailServer names, temp
directories for file uploads, etc, etc. Perhaps all these need to be
changed for deployment, with CS you are altering one conf file, not
any code at all.
Writing Factories is challenging and fun, definitely a great learning
experience, and no one is trying to dissuade you from learning, or
for that matter, doing whatever you need to do to make your
application great. However, you may want to read this article and
think about some of the points that are made about developing
EVERYTHING in-house:
http://www.joelonsoftware.com/articles/fog0000000007.html
On Dec 18, 2005, at 8:52 PM, Jason Daiger wrote:
For me he did and didn't. I've read it and re-read Dave's post
several
times now and still cannot get around a few things.
- First, the DAO example on the IoC portion isn't as complete as the
DAOFactory or Service Locator. It seems at the end that he waves
his hands
and says w/ 3 lines of XML it will work and you'll never need to
code a
Factory by hand again.
- Second, doesn't the IoC hide the dependencies in the similar
fashion as
the Service Locator does? And isn't that part of the point of
using IoC?
Joe Rinehart's post about Anemic Domains,
http://clearsoftware.net/index.cfm?mode=entry&entry=33C8370A-
E081-2BAC-69489
A4F0A7A3576, brought about similar thoughts for me on this issue
as well.
As did your follow-up on Domain Models and Dependency Injection,
http://corfield.org/blog/index.cfm/do/blog.entry/entry/
Domain_Models_and_Dep
endency_Injection. But your examples helped frame these issues
better and
helped me understand a bit more especially the refactoring b/w
examples 4 &
5.
-And third, any way you look at it someone needs to change
something to make
the new DSN required for DAO #7 to work. Either the DAOFactory is
tweaked,
the Service Locator is altered or the IoC gets updated but each of
them is
changed. So for me the question becomes who makes this change and
which
method is the least invasive and easiest for future developers
maintaining
the code to understand. It's the future developers part that tends
to get me
in the gut when I think about future maintenance.
In the end I'm having a hard time trying to justify the effort to
move to an
IoC framework (Service Locator just doesn't feel like a really at the
moment) versus the UberFactory approach. The drawbacks of the
UberFactory
approach appear to be more manageable than introducing the IoC layer.
Especially when I think about a maintenance programmer trying to
track down
a bug who has little or no knowledge about the IoC layer. At least
w/ the
UberFactory the tools are in place for them to attempt to begin to
unwind a
single method call without too much pain.
Perhaps part of my struggle in trying to understand and come to
grips w/
these issues is attempting to migrate my thinking to more of a service
approach and less of an object approach. It just seems the
UberFactory
approach removes some dependencies and appears easier to convert
into a
service model over the IoC approach. But of course I could be
totally wrong
and that's part of the fun (and frustration) of this line of work.
-Jason Daiger
----------------------------------------------------------
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]
----------------------------------------------------------
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]
