人云亦云固然是不大好，但连人家说什么都不懂就敢开口似乎更加不好。

Martin Fowler的文章《IoC容器和Dependency Injection模式》（IoC Container and Dependency Injection Pattern）的唯一中文版本是由我翻译的，但我――不论是翻译时还是现在――从来没有看出他“更倾向于service locator模式”，更没有看出他“认为IOC模式不利于理解”。所以你这话让我有点如芒在背：如果真有这层意思而我没有看出来，我的翻译岂不是有滥竽充数之嫌了？所以还请不吝赐教，请问究竟从哪里看出Martin Fowler的这些观点？我在这里先行谢过了。

spring 包含了很多模块，我澄清一下我的提法“struts+POJO与struts+spring IOC 的区别在哪里呢？”

究竟好在哪里？不能说因为是IOC,所以好！

我看到的一些理由是：

1.易于测试（针对ejb、jndi的难于测试）

2.可以动态配置，替换部件。

3.不用写singleton

但我感觉这几条都不足以说明非IOC不可，理由如下：

1 易于测试很好，但采用service locator也是可以测试的，据板桥说ejb也能测试（我不熟悉ejb）。

2 只要是对接口编程，就可以做到部件替换。

3 减少singleton很好，但效益有限。

引入框架的副作用是有几点：

1 学习成本,你必须学习配置文件的写法，相当于学习一个小的语言。(pico container不需要写配置文件)

2 依赖性

3 复杂性

市场上总是充满了吆喝，小品叫呼悠，英语叫hype,有意的无意的。Rod Jonson是一个优秀的设计者，但他也是要谋生的人，不是神，中国人有造神这个爱好。

每当有人向你推销万能药的时候，一定要打起精神多一些独立的批判性思考。

最后，我写这些只是为了学习探讨，如果你觉得很肤浅可以不予理睬，但不要开口就教训人，不管你名气多大，请用事实说话！

正确。但是要测试EJB必须将其部署到application server，这将使每个“测试-编程”的循环被严重拉长，实际上破坏测试先行的开发方法。

>>2 只要是对接口编程，就可以做到部件替换。

正确。

>>3 减少singleton很好，但效益有限。

不正确。Singleton之类创建型模式是一种实现细节，不应该在接口上暴露。最典型的例子，如果用经典方式（GoF书中介绍的方式）实现Singleton，你无法在不修改代码的前提下把它改为prototype。对象的创建应该由容器统一管理。

IoC与Service Locator真正的本质区别在于：如果使用Service Locator，那么组件的使用者必须与“组件的创建”（也就是Service Locator）耦合；如果使用IoC，组件的使用者不需要与组件的创建耦合，因此组件更具可移植性。这才是选择这两个模式的标准：你是否允许组件的使用者与组件的创建耦合。如果允许，Service Locator会很好；如果不允许，你需要IoC。其他的，从Martin Fowler这篇文章就可以看到，基本上是设计细节。

>>Rod Jonson是一个优秀的设计者，但他也是要谋生的人，不是神，中国人有造神这个爱好。每当有人向你推销万能药的时候，一定要打起精神多一些独立的批判性思考。

很好，我欣赏这样的态度。我――向Rod Johnson学来的――经常说：你不要相信任何人的建议，同样不要相信我的建议。你应该相信你自己的vertical slice，用template application去检验一项技术是否适合你的应用。我最反感的就是“要是不懂EJB，你就没资格谈论企业级应用”这样的态度，相信你也会与我有同感。