Google Guice与PicoContainer的依赖注入

Question

我的团队正在研究依赖注入框架,并试图决定使用Google-Guice和PicoContainer.

我们正在寻找框架中的几件事:

1. 代码占用空间小 - 我的意思是代码占用空间很小,我们不希望代码库中的依赖注入代码丢失.如果我们需要在路上进行重构,我们希望它尽可能简单.
2. 性能 - 创建和注入对象时每个框架有多少开销？
3. 易于使用 - 是否有很大的学习曲线？我们是否必须编写大量代码才能使简单的工作变得简单？我们想要尽可能少的配置.
4. 社区规模 - 较大的社区通常意味着将继续维护项目.我们不想使用框架并且必须修复我们自己的错误;)我们在此过程中遇到的任何问题都可以(希望)由框架的开发人员/用户社区来回答.

将非常感谢两个框架与所列标准的比较.任何有助于比较两者的个人经历也会非常有帮助.

免责声明:我对依赖注入相当新,如果我问一个与本次讨论无关的问题,请原谅我的新闻.

Answer 1

您可能希望将Spring包含在您正在考虑的依赖注入框架列表中.以下是您的问题的一些答案:

耦合到框架

Pico - Pico倾向于阻止二传手注射,但除此之外,你的课程不需要了解Pico.它只是需要知道的布线(对于所有DI框架都是如此).

Guice - Guice现在支持标准的JSR 330注释,因此您不再需要在代码中使用Guice特定的注释.Spring还支持这些标准注释.Guice家伙使用的论点是,如果没有运行Guice注释处理器,如果您决定使用不同的框架,这些应该不会产生影响.

Spring - Spring旨在让您避免在代码中提及Spring框架.因为它们确实有很多其他帮助程序/实用程序等,但依赖于Spring代码的诱惑非常强烈.

性能

Pico - 我不太熟悉Pico的速度特性

Guice - Guice设计得很快,参考文献中提到的比较有一些数字.当然,如果速度是主要考虑因素,则应考虑使用Guice或手工布线

春天 - 春天可能很慢.已经有工作使其更快,并且使用JavaConfig库可以加快速度.

便于使用

Pico - 配置简单.Pico可以为您做出一些自动装配决定.不清楚它如何扩展到非常大的项目.

Guice - 配置简单,只需添加注释并从AbstractModule继承即可将事物绑定在一起.随着配置保持最小,可以很好地扩展到大型项目.

Spring - 相对容易配置,但大多数示例使用Spring XML作为配置方法.随着时间的推移,Spring XML文件会变得非常庞大和复杂,并且需要花时间加载.考虑使用Spring和手摇依赖注入的混合来克服这个问题.

社区规模

皮科 - 小

Guice - 中等

春天 - 大

经验

Pico - 我对Pico没有多少经验,但它不是一个广泛使用的框架,因此更难找到资源.

Guice - Guice是一个流行的框架,当你有一个大型项目在开发中重新开始时,它对速度的关注是受欢迎的.我对配置的分布式特性感到担忧,即不容易看出整个应用程序是如何组合在一起的.在这方面,它有点像AOP.

Spring - Spring通常是我的默认选择.也就是说,XML可能会变得很麻烦,导致的减速很烦人.我经常最终使用手工制作的依赖注入和Spring的组合.当您真正需要基于XML的配置时,Spring XML非常好.Spring也花费了很多精力来使其他框架更加依赖于Dependency Injection,这可能很有用,因为他们在这样做时经常使用最佳实践(JMS,ORM,OXM,MVC等).

参考

• 微微
• 吉斯
• 弹簧
• Spring/Guice/Pico比较
• 另一个Spring/Guice性能比较

Answer 2

通过jamie.mccrindle竖起其实答案是相当不错的,但我感到困惑,为什么春天是默认的选择时,它很清楚,卓越的替代品(包括碧和吉斯)可供选择.IMO Spring的受欢迎程度已经达到了顶峰,现在它已经过了生成的炒作(以及所有其他"我也是"Spring子项目希望乘坐Spring的潮流).

Spring的唯一真正的优势是社区的规模(和很坦率地说,由于规模和复杂性,它需要),但微微和吉斯并不需要,因为他们的解决方案是更清洁,更有条理,更优雅的一个庞大的社区.Pico似乎比Guice更灵活(你可以在Pico中使用注释,或者不是 - 它非常有效). (编辑:意思是说它非常灵活,并不是说效率也不高.)

Pico的小尺寸和缺乏依赖性是一个不可低估的主要胜利.你现在需要下载多少个meg才能使用Spring？这是一个巨大的jar文件,包含所有依赖项.直观地思考,这样一个高效且"小"的解决方案应该比Spring更好地扩展和执行.Spring的臃肿真的会让它更好地扩展吗？这个奇异的世界吗？在证明(并解释)之前,我不会假设Spring"更具可扩展性".

有时创造一些好东西(Pico/Guice),然后保持你的HANDS关闭而不是添加膨胀和厨房水槽功能与无尽的新版本真的确实有效...

Answer 3

注意:这更像是评论/咆哮而不是答案

PicoContainer很棒.如果他们只修复他们的网站,我会切​​换回它.现在真的很混乱:

• http://picocontainer.com这是最新的,但很多页面都有格式问题,有些页面根本不起作用.看起来页面是从旧内容自动转换的.
• http://picocontainer.codehaus.org/在版本2.10.2中看起来似乎已经冻结了 - 如果页面上写着"嘿,你正在看旧网站的话",那将是非常好的.
• http://docs.codehaus.org/display/PICO/Home - 一个记录v 1.x的汇总维基,但它没有说明页面上的任何地方!

我现在正在使用Guice 2.x,即使它更大,但功能更少.找到文档要容易得多,而且用户组非常活跃.然而,如果Guice 3的方向是任何迹象,看起来Guice开始膨胀,就像Spring早期做的那样.

更新:我向Pico Container人员发表了评论,他们对网站进行了一些改进.现在好多了!