还想谈谈IOC。。。

08-10-13 bloodrate
              

今天看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接近服务理念,服务的目的就是服务的变化相对于服务使用者透明。。。。。。

              

1
banq
2008-10-14 09:57

我完全同意你的说法,POJOs IN ACTION这段话显示作者非常幼稚。

JNDI是一种运行环境的组件解耦,类似SOA概念,MF也提到依赖注射时,将JNDI看成依赖注射的一种,最原始的一种,这是正确的,想象一下,你需要服务器的DataSource,那么你的程序部署到服务器运行时,服务器就会将你需要的DataSource注射给你,这很明显是一种依赖注射,反转依赖。

POJOs IN ACTION是有阴谋背景的,就是为反EJB而反对,反对一切,这是因为作者的视野决定的。所以今天的书籍和以前不一样,因为讲究包容性,讲究百花齐放,毒草和鲜花同时存在,如果没有批判独立精神,很容易被误导,特别是对于初学者,走了一段弯路不说,浪费时间精力。

在今天EJB3中,JNDI还是正常存在,JNDI只需要代码提供一个名词String字符就可以注射,而IOC至少需要代码接口,从解耦上看,JNDI比IOC更松耦合。

如果从SOA分布式组件上看,也就是楼主的观点,JNDI更是一种灵活的解决方案。

[该贴被banq于2008-10-14 10:00修改过]

bloodrate
2008-10-14 11:04

看起来,把IOC定位为“组件注册表”还不是很合适,但是光作为一个工厂来用,也蛮好的,IOC工厂很像是一个扩充了很多功能的一般工厂,正是扩充的这些功能,鼓励开发人员面向领域建模,激励开发人员多写POJO,少写过程代码。

banq
2008-10-14 11:44

IOC不是一个组件注册表,是一种模式,解决依赖关系的方式,JNDI Server才更像一个组件注册表。

IOC也有工厂之类性质,特别是结合构造器注射的情况下,IOC解决了对象创建时的依赖关系,所以,而对象创建属于工厂模式,所以,IOC顺带也表现一种工厂模式。

>鼓励开发人员面向领域建模,激励开发人员多写POJO,少写过程代码。

其实,POJO已经是一个过时概念,因为在当前架构下,只要有流行新的框架支持,你编写的JavaBeans或class基本就是POJO。所以,POJO更多是对框架设计者的一种要求,你的框架设计得不能让使用者依赖你的框架,这句话以前是对EJB2说的,也适合其他框架和工具,所以我为什么一直对OSGI感冒,就是因为OSGI组件对框架Eclipse等有所依赖,当然可能现在已经有所改进。

[该贴被banq于2008-10-14 11:47修改过]