Google与PicoContainer的依赖注入

Question

我的团队正在研究依赖注入框架，并试图在使用Google和PicoContainer之间做出决定。

我们正在我们的框架中寻找几样东西：

1. 一个小的代码占用空间--我的意思是，我们不希望在代码库中到处都有依赖项注入代码。如果我们需要重建道路，我们希望它是尽可能容易的。
2. 性能-每个框架在创建和注入对象时有多少开销？
3. 易用性-有很大的学习曲线吗？我们是否需要编写大量的代码来实现一些简单的工作呢？我们希望有尽可能少的配置。
4. 社区规模-更大的社区通常意味着一个项目将继续保持。我们不想使用框架，必须修复我们自己的bug ;)此外，我们沿途遇到的任何问题都可以(希望)由框架的开发人员/用户社区来回答。

非常希望将这两个框架与所列标准进行比较。任何有助于比较两者的个人经历也会非常有用。

免责声明:我对依赖注入相当陌生，所以如果我问了一个与这个讨论无关的问题，请原谅。

Answer 1

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

与框架的耦合

Pico - Pico倾向于阻止setter注入，但除此之外，您的类不需要了解Pico。只需要知道连接(对于所有DI框架都是正确的)。

Guice - Guice现在支持标准的JSR 330注释，所以在代码中不再需要Guice特定的注释了。Spring还支持这些标准注释。Guice人员使用的论点是，如果不运行Guice注释处理器，如果您决定使用不同的框架，这些处理器就不会产生影响。

Spring - Spring旨在使您避免在代码中提到Spring框架。但是，由于他们确实有很多其他的助手/实用程序等等，所以依赖Spring代码是很有吸引力的。

性能

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

Guice -Guice被设计为快速的，参考文献中提到的比较有一些数字。当然，如果速度是首要考虑因素，无论是使用Guice还是手工布线都应该考虑。

Spring -春天可能很慢。为了使它更快，已经做了一些工作，使用JavaConfig库可以加快速度。

易用性

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

Guice --配置简单，只需添加注释并从AbstractModule继承来将事物绑定在一起。当配置保持在最小时，就可以很好地扩展到大型项目。

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

社区规模

Pico - Small

Guice -介质

Spring -大型

体验

Pico -我对Pico没有太多的经验，但它不是一个广泛使用的框架，因此很难找到资源。

Guice -Guice是一个流行的框架，当您有一个正在开发中重新启动的大型项目时，它对速度的关注是受欢迎的。我担心配置的分布式性质，即很难看到我们的整个应用程序是如何组合在一起的。在这方面有点像AOP。

Spring -Spring通常是我的默认选择。尽管如此，XML可能会变得很麻烦，由此产生的减速会让人讨厌。最后，我经常使用手工构建的依赖注入和Spring的组合。当您实际需要基于XML的配置时，Spring非常好。Spring还花费了大量精力使其他框架更加依赖注入友好，这可能很有用，因为它们在使用时经常使用最佳实践(JMS、ORM、OXM、MVC等)。

参考文献

• 皮科
• 盖斯
• 春天
• 春季/ Guice / Pico比较
• 另一种Spring / Guice性能比较

Answer 2

jamie.mccrindle给出的答案实际上相当不错，但我不明白为什么Spring是默认的选择，因为很明显，优秀的替代方案( Pico和Guice)都是可用的。IMO Spring的受欢迎程度已经达到了顶峰，现在它正依赖于所产生的炒作(以及所有其他的"me“Spring子项目都希望赶上Spring的潮流)。

Spring唯一真正的优势是社区规模(坦率地说，由于其规模和复杂性，它是必需的)，但是Pico和Guice并不需要一个庞大的社区，因为他们的解决方案更干净、更有条理、更优雅。Pico似乎比Guice更灵活(您可以在Pico中使用注释，也可以不使用注释--它非常高效)。(编辑:意思是说它非常灵活，并不是说它也没有效率)。

Pico的小规模和缺乏依赖性是一个重要的胜利，不应该被低估。您现在需要下载多少个megs才能使用Spring？这是一堆乱七八糟的大jar文件，还有所有的依赖项。从直觉上看，这样一个高效且“小”的解决方案应该比Spring这样的解决方案具有更好的规模和性能。春天的膨胀真的会让它变得更好吗？这是个奇怪的世界吗？在证明(并解释)之前，我不会假设Spring是“更可伸缩的”。

有时创造一些好的东西(Pico/Guice)，然后让你的手远离它，而不是用无穷无尽的新版本增加膨胀和厨房水槽功能，这确实有效.

Answer 3

注:这与其说是回答，不如说是评论/咆哮。

PicoContainer很棒。如果他们能修复他们的网站，我会改回去的。现在真让人困惑：

• http://picocontainer.com是最新推出的，内容为v2.15，最近一次更新是2014年，但很多页面都存在格式化问题，一些页面根本无法工作。看起来这些页面是从旧的内容中自动转换出来的。(注:2014年可能不再是这种情况)。
• 在2.10.2版的时候，https://web.archive.org/web/20150516190836/http://picocontainer.codehaus.org/似乎被冻结了--如果页面上写着“嘿，你在看一个老网站！”的话，这将是一个非常好的！
• https://web.archive.org/web/20150516190836/http://picocontainer.codehaus.org/ -文档v1.x的汇合wiki，但它并没有在页面上这样说！

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

更新:我向发布了一条评论，他们对网站做了一些改进。现在好多了!