还想谈谈IOC。。。
今天看POJOs IN ACTION书中有类似这样一段话“传统的J2EE应用程序使用JNDI作为一个组件访问另外一个组件的依据，比如JNDI访问EJB组件，JNDI访问Datasource获取服务器上的数据库连接池中的连接，但是JNDI的弱点在于它把应用程序和应用服务器耦合在一起，难于测试和维护。而Spring提供的IOC可以提供一种更为灵活的一个组件访问一个另一个组件的机制，并且与应用服务器脱离耦合。”
那么我可以简要分析出，IOC是某种意义上是作为JNDI的取代品出现的，这也和Martin Fowler对IOC的讲法一致：IOC作为一个系统中“组件插槽”的身份出现的，IOC鼓励程序员基于组建开发督促程序员多写POJO，而绝非是DaoFactory这样的工厂类替代品。
那么我产生疑惑，IOC作为一个系统访问各个基础组件的访问机制，是否能起到真正作用呢？是否它真的比JNDI强呢？考虑这样一种情况：如果一个很大型的系统，有很多子系统，而这些子系统有公用了一些服务，由你来开发这个服务。
如果是JNDI，你将服务部单独署在应用服务器里，然后告诉每个系统负责人你的JNDI，他们就可以访问使用，如若你想维护更新修改你的服务，你只需进行自己的修改而不用告诉大家，因为大家只用你的jndi接口。如果是IOC，你维护了你自己写的服务，还要告诉大家“喂，开会了，大家把我新写的JAR拷走吧，部署在你们的classpath下”这看起来没什么，但是子系统多了，难免出现版本混乱问题。
我是觉得IOC确实看起来只像是一个工厂，而不像一个注册服务的地方。至少它没能让服务组件实现“可单独维护”，反而JNDI接近服务理念，服务的目的就是服务的变化相对于服务使用者透明。。。。。。