Guice与Spring框架的区别

2007-4-23 

再借斧子的例子说一说spring与guice的区别

    看下边对于不同社会形态下一个人（java对象，调用者）需要一把斧子（java对象，被调用者）的例子：

（1），原始社会时，劳动社会基本没有分工，需要斧子的人（调用者）只好自己去磨一把斧子，每个人拥有自己的斧子，如果把大家的石斧改为铁斧，需要每个人都要学会磨铁斧的本领，工作效率极低。

对应Java里的情形是：java程序里的调用者new一个被调用者的实例。类耦合度极高，修改维护烦琐，效率极低。

（2），工业社会时，工厂出现，斧子不再由普通人完成，而由工厂生产，当人们需要斧子的时候，可以到工厂购买斧子，无需关心斧子是怎么制造出来的，如果废弃铁斧为钢斧，只需改变工厂的制造工艺即可，制作工艺是工厂决定的，工厂生产什么斧子，工人们就得用什么斧子。

 对应的Java里的情形是：Java程序的调用者可以以来简单工厂创建被调用者，变化点被隔离到了简单工厂里，虽然耦合度降低，但是调用者会和工厂耦合，而且需要定位自己的工厂。

（3）近代工业社会，工厂蓬勃发展，人们需要什么斧子，只需要提供一个斧子图形，商家会按照你提供的图形将你的斧子订做好，送上门。

对应Java里的情形：spring的依赖注入

（4）进入按需要分配社会，信息进入现代化，人们不再去工厂购买斧子，不再拘泥于需要什么斧子事先画好什么样的图形，只需要打个电话，描述一下需要什么类型的斧子，或许想打造一个物美价廉的斧子，商家会根据市场零件的价格，计算出最优制作工艺,打造最适合的斧子送过来，更加信息化，更加人性化。

 对应Java里的情形：基于描述的注入，动态的，灵活简单的注入，如：Guice。

 

    对于该不该使用Guice,我想也是仁者见仁,智者见智,就象好多论坛里动不动有人会在那里讨论到底学Java还是学.net或者是使用eclipse还是Jbuilder的这类无聊话题,适合和满足项目需求的,又能省工省力简单的完成工作的,就是最好的。

***************************************************************

guice和spring的有状态和无状态的区别

2011/8/16 

最近在看谷歌的guice，看到和spring的stateless和stateful设计有一些不同的地方，随便分析下，想想以后再来看会不会有另外的收获。 

谷歌guice： 

If the object is stateful, the scoping should be obvious. Per-application is @Singleton, per-request is @RequestScoped, etc. If the object is stateless and inexpensive to create, scoping is unnecessary. Leave the binding unscoped and Guice will create new instances as they're required. 

如果这个对象是有状态的，那么它的scope是很明显的。每一个应用程序都是单例的scope，每一个http请求都是一个http请求的scope等等。如果这个对象是无状态的，并且创建不昂贵，scope是没有必要的。给一个绑定不加scope，当一个实例需要的时候，Guice就会自动创建一个。 

Singletons are popular in Java applications but they don't provide much value, especially when dependency injection is involved. Although singletons save object creation (and later garbage collection), getting a handle to the single instance requires synchronization. Singletons are most useful for: 

单例在java应用程序中非常流行，但是他们没有提供太多的值，尤其是在依赖注入被调用的时候。尽管单例保存了对象创建（然后垃圾回收），获取一个单例的句柄需要同步。单例在以下情况有用。 

stateful objects, such as configuration or counters 

有状态的对象，例如配置文件和计数器

objects that are expensive to construct or lookup 

花费很大的代价来构造或者查找的对象 

objects that tie up resources, such as a database connection pool. 

连接到外部资源的对象，例如数据库连接池。 

spring framework： 

As a rule, use the prototype scope for all stateful beans and the singleton scope for stateless beans. 

作为一个规则，所有有状态bean用原型的scope，所有没有状态的bean用单例scope。 

这中间就有一个冲突， 

spring希望把所有的无状态的对象都作为单例，当然也包括那些确实需要单例来完成情况 

guice只是希望把那些真正需要单例对象作为单例，其他无状态的对象（可做可不做的）都声明为unscoped。 

我觉得这时两家设计哲学的问题。 

spring作为一个重量级的依赖注入框架，使得放在spring容器中的bean可以添加后置处理器、消息资源等额外特性。把所有的无状态的类声明为单例bean从而添加这些特性。 

而guice作为一个轻量级的依赖注入框架，没有spring那么多的后置处理器、消息资源等东西，它相信大部分人使用对象是“创建它，使用它，然后废弃它（create it, use it and toss it)”，没有必要把所有的对象纳入guice容器管理。如果纳入其中管理，损耗内存，而且拖慢启动速度。 

但是这需要使用者有较高的程序素养，就是什么时候真的需要使用单例，一个对象的创建到底花多长时间创建才需要定为单例？没有一个明确的规则，正所谓增加灵活性的同时也增加复杂性。因此guice在这点和spring相比各有千秋。个人觉得gucie适合有修养的程序员，而spring都适合绝大部门程序员。 

一家之言，还请拍砖。