Question

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

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

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

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

免责声明：我对依赖注入相当陌生，如果我问一个与本次讨论无关的问题，请原谅我的新闻。

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和手摇依赖注入的混合来克服这个问题。

社区规模

Pico - 小

Guice - 中等

春天 - 大

体验

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

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

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

参考

Answer 2

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关闭而不是添加膨胀和厨房水槽功能与无尽的新版本真的确实有用......

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的人发了评论，他们对网站做了一些改进。现在好多了！

Answer 4

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

Answer 5

如果您在简约DI容器之后，可以查看Feather。仅限Vanilla JSR-330 DI功能，但在占用空间（16K，无依赖性）和性能方面相当不错。适用于Android。

Answer 6

虽然我确实喜欢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();
}

Google Guice与PicoContainer的依赖注入

6 个答案:

耦合到框架

效果

易于使用

社区规模

体验

参考