对 Guice Interceptor 的一点 自己 的看法

对 Guice Interceptor 的一点 自己 的看法

最近 一直 在 听 Google 吹 自己得 Ioc 框架 --Guice,自己 也小 用了 一下 ,感觉 还是 比 Spring要 更加 得体谅 程序员 ,解放生产力 ,把所有 得 耦合 转移到 了 Injector和 框架 中,哦 顺便发 一下 牢骚,Spring真的 是 在欺骗所有程序员,所谓 得无侵入式注入,就是 把所有 得耦合转移 到 配置文件,通过框架来弥补配置文件所带来得不足,毕竟他得配置文件只是 单纯得Xml,没有做个编译器,只有提供框架来解释,其实大家仔细看一下Spring得 配置文件,足够做一个脚本语言了,更别说别得,做一个项目首先要配备一个配置工程师,来管理所有得配置文件,再有就是配置文件得调试,万一哪里写错了,足够你调上一天…………好了不发牢骚了,说正经得

Guice就 好比没有成熟得Ioc一样,所有得 都给你做好了,唯独Interceptor没有做,而将代码得耦合集中到Injector,这样调试也是很方便得,但你每次使用前都要先出现Injector,如下代码 :

Client client = new Client();//需要 注入得类
ClientModule module = new ClientModule();//写好Binder得 类
Injector injector = Guice.createInjector(module);//得到 Injector
injector.injectMembers(client);//进行注入

这样一来,Guice就是没有给你做Interceptor,不能自己拦截必要得请求进行自动注入,每次需要使用时需要手动注入,所以曾经自己用AspectJ写过小得拦截器,拦截请求后使用Injector进行注入,这样一来就省力很多,业务层代码也显得相当得简洁,可拦截器并不是我写得那么简单,需要涉及很多得问题,我经验尚浅,希望大家 指点一下,谢谢。哦对了,哪天Spring要 出个配置文件编译器,估计一门新得脚本语言就真的诞生了¥¥¥¥¥

还有就是Guice出了做了个半自动得依赖注入框架,就是说,如果你得一个类中需要多个依赖注入,那么用Guice只需要使用Injector注入一次,就可以满足需要,这不就是所谓得半自动吗?比尼自己new 一个对象在使用setter是节省了一些代码,还有就是他把耦合转移到了那个Module中,就是哪天你得实现类变了,需要更改得 是Module中得Binder参数,而不是业务层中new出来得那么多对象,这一点还是值得肯定得

Ioc/DI有两种注射方式:Spring的手工和Pico/jdon/Seam的自动注射auto-wiring。看来Guice是介于两者之间的一个半自动注射。

因为注射配对实际是一个劳动力工作,类多了就烦琐重复,框架如果能根据类型自动配对进行注射,就比写代码或写配置要方便多啊。


其实所谓得依赖注入,总感觉是一种理想化得东西,毕竟代码之间得耦合肯定是会存在得,除非你把所有得业务逻辑写成一个Mr。Know All类,这个我没话说,如果要做依赖注入,不是单纯得减少耦合性,在一定程度上还是要转移耦合,Spring将耦合完全转移到了配置文件,使得代码是绝对得松耦合而配置文件却是完全得紧耦合,而配置文件是不能调试得,这个我上面也说到了,这样必然会带来开发效率得低下,Guice是把所有得依赖注入都显示得交给了自己得框架,如果你要依赖注入,那好啊,自己去调用Injector吧,而配置方面交给了代码,就是所谓得Module,但我们在业务层直接调用Injector总感觉在手工注入,但甚么东西都不用,哪里有那么智能得东西哦,要真有,程序员早解放了

所以我才有这么一个想法,就是每个类中都加一个token,boolean类型,代表是否已经被注入,然后规定代码包,每个需要注入得类得对应Module必须方在当前包得inject子包下面,然后使用AspectJ拦截对应类得操作,在类名中加上inject找到Module,使用反射得到实例进行注入,然后把token设置成true,下次拦截后直接检查token就可以决定是否需要再次注入了 ,不知这样得思路可不可以,还是希望大家指点一些

>毕竟代码之间得耦合肯定是会存在得,..如果要做依赖注入,不是单纯得减少耦合性,在一定程度上还是要转移耦合

可以说转移耦合了,只有依赖接口和DI框架了。

关于依赖自动注射,在上面前提下,类与类之间的注射可以有框架自动解决,无需配置或代码,框架根据注册容器中的接口类型,自动寻找需要被注射的类型,如果一个类XXX中有一个接口类型为AI对象属性,那么在DI框架就会在整个DI容器中寻找AI类型的实现子类,如果有,就将这个子类创建为实例,自动注射引导入类XXX中,类似框架写了一段Guice的那段注射代码。

自动注射Auto-wiring最早应用是Pico,现在JBoss Seam也引入,所以,在Seam 2.0出来时,有人在TSS跟帖把Spring的Ioc/DI手工依赖注射归于上一个世纪的技术。
http://www.jdon.com/jivejdon/thread/32192.html

那怎么找到实现接口的那个类呢?

如果一个接口被多个类继承,我又如何处理在注入时new哪个实现进行注入呢?
看来DI这个东西还不是那么太简单

>那怎么找到实现接口的那个类呢?
因为所有类都已经注册到一个集合中,使用构造参数反射机制就可以实现,我们已经知道Class.forName(类名).newInstance是生成无构造参数的对象,JDK API还提供了类似API用于带构造参数的对象创建方法。

如果一个接口有多个实现类,那么注册时就只能注册一个类。注册就是配置或通过元注释手段,这是auto-wiring的一个特点。

这也符合我们OO编程思路:一个接口有多个子类,一般不是同时使用的,而是替换使用,这样我们程序中就不会出现同一个接口两个以上实现子类分别同时在使用,如果出现,会让程序晦涩难懂,大部分模式中也不会出现两个以上子类同时使用。