问题
我的团队正在研究依赖注入框架，并试图决定使用Google-Guice和PicoContainer。
我们正在寻找框架中的几件事：
- 代码占用空间小 - 我所说的代码占用空间很小，我们不希望代码库中的依赖注入代码丢失。如果我们需要在路上进行重构，我们希望它尽可能简单。
- 性能 - 创建和注入对象时每个框架有多少开销？
- 易于使用 - 是否有很大的学习曲线？我们是否必须编写大量代码才能获得简单的工作？我们想要尽可能少的配置。
- 社区规模 - 较大的社区通常意味着将继续维护项目。我们不想使用框架并且必须修复我们自己的错误;)此外，我们在此过程中遇到的任何问题都可以(希望)由框架的开发人员/用户社区来回答。
将非常感谢两个框架与列出的标准的比较。任何有助于比较两者的个人经历也会非常有帮助。
免责声明：我对依赖注入相当新，所以如果我问一个与本次讨论无关的问题，请原谅我的诺言。
#1 热门回答(111 赞)
你可能希望将Spring包含在你正在考虑的依赖注入框架列表中。以下是你的问题的一些答案：
##耦合到框架
Pico- Pico倾向于阻止二传手注射，但除此之外，你的课程不需要了解Pico。它只是需要知道的布线(对于所有DI框架都是如此)。
Guice- Guice现在支持标准的JSR 330注释，因此你不再需要在代码中使用Guice特定的注释。 Spring还支持这些标准注释。 Guice家伙使用的论点是，如果没有运行Guice注释处理器，如果你决定使用不同的框架，这些应该不会产生影响。
Spring- Spring旨在允许你避免在代码中提及Spring框架。因为他们确实有很多其他助手/实用程序等，但依赖于Spring代码的诱惑非常强烈。
##性能
Pico-我不太熟悉Pico的速度特性
309167618 Guice**- Guice设计得很快，参考文献中提到的比较有一些数字。当然，如果速度是首要考虑因素，则应考虑使用Guice或手工布线
春天-春天可能很慢。已经有工作使它更快，使用JavaConfig库应该加快速度。
使用方便
Pico-配置简单。 Pico可以为你做出一些自动装配决定。不清楚它如何扩展到非常大的项目。
Guice-配置简单，只需添加注释并从AbstractModule继承即可将事物绑定在一起。随着配置保持最小，可以很好地扩展到大型项目。
Spring-相对容易配置，但大多数示例使用Spring XML作为配置方法。随着时间的推移，Spring XML文件会变得非常庞大和复杂，并且需要花时间加载。考虑使用Spring和手摇依赖注入的混合来克服这个问题。
##社区规模
Pico-小
Guice-中等
春天-大
##经验
Pico-我对Pico没有多少经验，但它不是一个广泛使用的框架，因此更难找到资源。
Guice- Guice是一个流行的框架，当你有一个大型项目在开发中重新开始时，它对速度的关注是受欢迎的。我对配置的分布式特性感到担忧，即不容易看出整个应用程序是如何组合在一起的。在这方面，它有点像AOP。
Spring- Spring通常是我的默认选择。也就是说，XML可能会变得很麻烦，并且由此导致的减速很烦人。我经常最终使用手工制作的依赖注入和Spring的组合。当你真正需要基于XML的配置时，Spring XML非常好。 Spring还花了很多精力使其他框架更加依赖于依赖注入，这可能很有用，因为它们在执行此操作时经常使用最佳实践(JMS，ORM，OXM，MVC等)。
##参考文献
- 皮科
- Guice
- 春天
- Spring / Guice / Pico比较
- 另一个Spring / Guice性能比较
#2 热门回答(25 赞)
jamie.mccrindle提出的答案实际上相当不错，但是我很困惑为什么Spring是默认选择，因为很明显可以使用优质替代品(Pico和Guice)。 IMO Spring的受欢迎程度达到了它的最高点，现在它正在生成炒作(以及所有其他"我也是"Spring子项目希望乘坐Spring的潮流)。
Spring的唯一真正优势是社区规模(坦率地说，由于规模和复杂性，它是必需的)，但Pico和Guice没有进入庞大的社区，因为他们的解决方案更清洁，更有条理，更优雅。 Pico似乎比Guice更灵活(你可以在Pico中使用注释，或者不是 - 它非常有效).(编辑：意思是说它非常灵活，而不是它也没有效率。)
Pico的小尺寸和缺乏依赖性是一个不可低估的主要胜利。你需要下载多少个meg才能使用Spring？这是一个巨大的jar文件，包含所有依赖项。直观地思考，这样一个高效且"小"的解决方案应该比Spring更好地扩展和执行。 Spring的臃肿真的会让它更好地扩展吗？这个奇异的世界吗？在证实(并解释)之前，我不会假设Spring"更具可扩展性"。
有时创造一些好东西(Pico / Guice)，然后保持你的HANDS关闭而不是添加膨胀和厨房水槽功能与无尽的新版本真的确实有效...
#3 热门回答(11 赞)
注意：这更多是评论/咆哮而不是答案
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人员发表了评论，他们对网站进行了一些改进。现在好多了！