102

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

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

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

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

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

4

6 回答 6

117

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

耦合到框架

Pico - Pico 倾向于阻止 setter 注入，但除此之外，您的课程不需要了解 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 还付出了很多努力来使其他框架对依赖注入更友好，这很有用，因为它们在这样做时经常使用最佳实践（JMS、ORM、OXM、MVC 等）。

参考

于 2010-01-08T14:02:12.963 回答
26

jamie.mccrindle 提出的答案实际上非常好，但是当很明显可以使用更好的替代方案（Pico 和 Guice）时，为什么 Spring 是默认选择让我感到困惑。IMO Spring 的受欢迎程度已经达到了顶峰，现在它正在靠产生的炒作（以及所有其他“我也是”Spring 子项目希望赶上 Spring 潮流）过活。

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

Pico 的小尺寸和缺乏依赖性是一个不容小觑的重大胜利。您现在需要下载多少兆才能使用 Spring？这是一个由大量 jar 文件组成的杂乱无章的文件，其中包含所有依赖项。直观地思考，这样一个高效且“小”的解决方案应该比 Spring 之类的解决方案具有更好的扩展性和性能。Spring 的膨胀真的会使其扩展性更好吗？这是奇异的世界吗？在证明（和解释）之前，我不会假设 Spring “更具可扩展性”。

有时创造一些好的东西（Pico/Guice），然后让你的手远离它，而不是添加臃肿和厨房水槽功能以及无穷无尽的新版本确实有效......

于 2010-07-22T02:28:22.860 回答
12

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

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

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

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

于 2011-05-12T19:05:28.077 回答
3

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

于 2014-01-29T16:40:22.367 回答
3

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

于 2015-09-30T12:13:38.413 回答
0

虽然我确实喜欢 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();
}
于 2012-10-22T10:51:59.313 回答