Google Guice与PicoContainer进行依赖注入

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

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

1. 较小的代码占用空间-我所说的较小的代码占用空间是我们不想在我们的代码库中到处都有依赖项注入代码垃圾。如果需要在将来进行重构，我们希望它尽可能简单。
2. 性能-创建和注入对象时，每个框架有多少开销？
3. 易于使用-学习曲线是否很大？我们是否必须编写大量代码才能使某些简单工作起作用？我们希望配置尽可能少。
4. 社区规模-较大的社区通常意味着将继续维护项目。我们不想使用框架，而不得不修复我们自己的错误；）此外，框架的开发人员/用户社区也可以（希望）回答我们所遇到的任何问题。

将两个框架与所列标准进行比较将不胜感激。任何有助于将两者进行比较的个人经验也将非常有帮助。

免责声明：我对依赖注入还很陌生，因此如果我提出的问题与本次讨论无关，请原谅我。

您可能希望将Spring纳入您正在考虑的Dependency Injection框架列表中。以下是您问题的一些答案：

耦合到框架

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。

春季 -春季通常是我的默认选择。就是说，XML可能变得很繁琐，并且导致速度变慢。我经常最终将手工制作的依赖注入和Spring结合使用。当您实际上需要基于XML的配置时，Spring XML相当不错。Spring还付出了很多努力来使其他框架更加依赖于依赖项注入，这很有用，因为这样做时它们经常使用最佳实践（JMS，ORM，OXM，MVC等）。

参考文献

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

jamie.mccrindle给出的答案实际上是很好的，但是当很明显有更好的选择（包括Pico和Guice）可用时，为什么让Spring是默认选择却让我感到困惑。IMO Spring的受欢迎程度已经达到顶峰，现在它已经摆脱了大肆宣传（以及其他所有希望借助Spring潮流的“我也是” Spring子项目）。

Spring的唯一真正优势是社区规模（坦率地说，由于规模和复杂性，这是必需的），但是Pico和Guice 不需要庞大的社区，因为它们的解决方案更干净，更有条理且更优雅。Pico似乎比Guice灵活（您可以在Pico中使用注释，也可以不使用注释-这非常有效）。 （编辑：是要说它非常灵活，而不是说它也不是很有效。）

Pico的体积小且没有依赖关系，这是一次重大胜利，不容小.。您现在需要下载几兆才能使用Spring？这是一个巨大的jar文件的杂乱无章，并带有所有的依赖关系。凭直觉思考，这样一种有效的“小型”解决方案应该比Spring这样的扩展和性能更好。Spring的膨胀真的会使其规模更好吗？这是古怪的世界吗？在证明（并说明）之前，我不会假设Spring具有“更大的可扩展性”。

有时创建一些好东西（Pico / Guice），然后使您的HANDS保持关闭，而不是通过无休止的新版本添加膨胀和厨房水槽功能，确实可以解决问题……

注意：这更多的是评论/回应而不是答案

PicoContainer很棒。如果他们只是修复他们的网站，我会切​​换回去。现在真的很混乱：

• 这是最新的http://picocontainer.com，但是许多页面存在格式问题，有些页面根本无法使用。页面似乎是从旧内容自动转换而来的。
• http://picocontainer.codehaus.org/在2.10.2版本中似乎冻结了- 如果页面说“嘿，您正在寻找一个旧网站！”，那真是太好了。
• http://docs.codehaus.org/display/PICO/Home-一个融合v.x文档的wiki，但是在页面的任何地方都没有说明v 1.x ！

我现在正在使用Guice 2.x，尽管它更大，并且功能更少。查找文档非常容易，并且用户组非常活跃。但是，如果Guice 3的方向有任何迹象，那么Guice似乎开始膨胀，就像Spring早年回归一样。

更新：我向Pico Container员工发布了评论，他们对网站进行了一些改进。现在好多了！

这是一个老问题，但是今天您可以在Android App项目中考虑使用Dagger（https://github.com/square/dagger）。Dagger在编译时进行代码生成。这样您可以缩短启动时间，并减少执行时间上的内存使用量。

如果您追求简约的DI容器，可以查看Feather。仅具有Vanilla JSR-330 DI功能，但在占用空间（16K，无依赖项）和性能方面都相当不错。适用于android。

尽管我喜欢PicoContainer的原因在于它的简单性和缺乏依赖性。我建议改用CDI，因为它是Java EE标准的一部分，因此您没有供应商锁定。

在侵入性方面，主要问题是需要一个容器并使用相对空的META-INF / beans.xml文件（需要表明jar正在使用CDI）和使用注释（尽管它们是标准的） ）

我用于自己的项目的轻型CDI容器是Apache Open Web Beans。尽管花了一段时间才弄清楚如何创建一个像这样的简单应用程序（与Pico不同）。

public static void main(final String[] args) {
    final ContainerLifecycle lifecycle = WebBeansContext.currentInstance()
            .getService(ContainerLifecycle.class);
    lifecycle.startApplication(null);

    final BeanManager beanManager = lifecycle.getBeanManager();
    // replace Tester with your start up class
    final Bean<?> bean = beanManager.getBeans(Tester.class).iterator()
            .next();

    final Tester b = (Tester) lifecycle.getBeanManager().getReference(bean,
            Tester.class, beanManager.createCreationalContext(bean));
    b.doInit();
}