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]
