Google guice

Guice还具有一些可选的特性比如:自定义scopes,传递依赖, 静态属性注入,与Spring集成和AOP联盟方法注入等。  
一部分人认为,Guice可以完全替代spring, 因为对于DI组件框架来说, 性能是很重要的, guice比spring快十倍左右, 另外, 也是最重要的一点, 使用spring很容易写成service locator的风格, 而用guice, 你会很自然的形成DI风格.  
甚至说,guice简单超轻量级的DI框架效率是spring的100倍,Spring使用XML使用将类与类之间的关系隔离到xml中,由容器负责注入被调用的对象,而guice将类与类之间的关系隔离到Module中,声名何处需要注入,由容器根据Module里的描述,注入被调用的对象,使用Annotation使用支持自定义Annotation标注,对于相同的接口定义的对象引用,为它们标注上不同的自定义Annotation注释,就可以达到同一个类里边的同一个接口的引用,注射给不同的实现,在Module里用标注做区分,灵活性大大增加。  
运行效率装载spring配置文件时,需解析xml,效率低,getBean效率也不高,不过使用环境不会涉及到getBean,只有生产环境的时候会用到getBean,在装载spring应用程序的时候,已经完成全部的注射,所以这个低效率的问题不是问题。使用Annotation,cglib,效率高与spring最明显的一个区别,spring是在装载spring配置文件的时候把该注入的地方都注入完,而Guice呢,则是在使用的时候去注射,运行效率和灵活性高。类耦合度耦合度低,强调类非侵入,以外部化的方式处理依赖关系,类里边是很干净的,在配置文件里做文章,对类的依赖性极低。高,代码级的标注,DI标记@inject侵入代码中,耦合到了类层面上来,何止侵入,简直侵略,代码耦合了过多guice的东西,大大背离了依赖注入的初衷,对于代码的可维护性,可读性均不利类编写时需要编写xml,配置Bean,配置注入只需声明为@inject,等着被注入.仅支持IOC否,spring目前已经涉猎很多部分是,目前仅仅是个DI容器是否易于代码重构统一的xml配置入口,更改容易配置工作是在Module里进行,和spring异曲同功支持多种注入方式构造器,setter方法Field,构造器,setter方法灵活性1,如果同一个接口定义的引用需要注入不同的实现,就要编写不同的Module,烦琐。  如果你想注射的一个实现,你还未知呢,怎么办呢,spring是没办法,事先在配置文件里写死的,而Guice就可以做到,就是说我想注射的这个对象我还不知道注射给谁呢,是在运行时才能得到的的这个接口的实现,所以这就大大提高了依赖注射的灵活性,动态注射。  
与现有框架集成度高
  1. 众多现有优秀的框架(如struts1.x等)均提供了spring的集成入口,而且spring已经不仅仅是依赖注入,包括众多方面。  
  2. Spring也提供了对Hibernate等的集成,可大大简化开发难度。  
  3. 提供对于orm,rmi,webservice等等接口众多,体系庞大。可以与现有框架集成,不过仅仅依靠一个效率稍高的DI,就想取代spring的地位,有点难度。配置复杂度在xml中定位类与类之间的关系,难度低代码级定位类与类之间的关系,难度稍高。
Guice与Spring的对比
  Spring Guice
使用XML 使用将类与类之间的关系隔离到xml中,由容器负责注入被调用的对象,因此叫做依赖注入 不使用xml,将类与类之间的关系隔离到Module中,声名何处需要注入,由容器根据Module里的描述,注入被调用的对象。
使用Annotation   使用
支持自定义Annotation标注,对于相同的接口定义的对象引用,为它们标注上不同的自定义Annotation注释,就可以达到同一个类里边的同一个接口的引用,注射给不同的实现,在Module里用标注做区分,灵活性大大增加。
使用Annotation也未必是好事,范型等新特性也未必是好事,目前大多的服务器均不支持jdk1.5,wls要9以前才支持,而目前的客户由于价格原因也很少选用wls9的,至少我们做过的项目中都没有。功能再强,客户不需要,何用?
运行效率 装载spring配置文件时,需解析xml,效率低,getBean效率也不高,不过使用环境不会涉及到getBean,只有生产环境的时候会用到getBean,在装载spring应用程序的时候,已经完成全部的注射,所以这个低效率的问题不是问题。 使用Annotation,cglib, 效率高与spring最明显的一个区别,spring是在装载spring配置文件的时候把该注入的地方都注入完,而Guice呢,则是在使用的时候去注射,运行效率和灵活性高。
类耦合度 耦合度低,强调类非侵入,以外部化的方式处理依赖关系,类里边是很干净的,在配置文件里做文章,对类的依赖性极低。 高,代码级的标注,DI标记@inject侵入代码中,耦合到了类层面上来,何止侵入,简直侵略,代码耦合了过多guice的东西,大大背离了依赖注入的初衷,对于代码的可维护性,可读性均不利
类编写时 需要编写xml,配置Bean,配置注入 只需声明为@inject,等着被注入,
最后在统一的Module里声明注入方式
仅支持IOC 否,spring目前已经涉猎很多部分 是,目前仅仅是个DI容器
是否易于代码重构 统一的xml配置入口,更改容易 配置工作是在Module里进行,和spring异曲同功
支持多种注入方式 构造器,setter方法 Field,构造器,setter方法
灵活性  

1,如果同一个接口定义的引用需要注入不同的实现,就要编写不同的Module,烦琐

2,动态注入

如果你想注射的一个实现,你还未知呢,怎么办呢,spring是没办法,事先在配置文件里写死的,而Guice就可以做到,就是说我想注射的这个对象我还不知道注射给谁呢,是在运行时才能得到的的这个接口的实现,所以这就大大提高了依赖注射的灵活性,动态注射。

与现有框架集成度 1, 高,众多现有优秀的框架(如struts1.x等)均提供了spring的集成入口,而且spring已经不仅仅是依赖注入,包括众多方面。
2, Spring也提供了对Hibernate等的集成,可大大简化开发难度。
3, 提供对于orm,rmi,webservice等等接口众多,体系庞大。
1,可以与现有框架集成,不过仅仅依靠一个效率稍高的DI,就想取代spring的地位,有点难度。
配置复杂度 在xml中定位类与类之间的关系,难度低 代码级定位类与类之间的关系,难度稍高

Guice的方法拦截也是通过动态生成字节码来实现的,通过创建子类重写相应的方法来实现拦截,不支持字节码生成的平台如Android就没法用了。

文档中还列出了被拦截的类与方法需要满足的条件:

1.类必须是public的或包内可见的;

2.类必须是非final的;

3.方法必须是public的、包内可见的或是protected的;

4.方法必须是非final的;

5.实例必须通过无参数的构造函数生成或者通过guice的@inject注解构造。

你可能感兴趣的:(Google guice)