Java Google Guice 与 PicoContainer 的依赖注入
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2026016/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Google Guice vs. PicoContainer for Dependency Injection
提问by austen
My team is researching dependency injection frameworks and is trying to decide between using Google-Guice and PicoContainer.
我的团队正在研究依赖注入框架，并试图在使用 Google-Guice 和 PicoContainer 之间做出决定。
We are looking for several things in our framework:
我们正在我们的框架中寻找几件事：
- A small code footprint - What I mean by a small code footprint is we don't want to have dependency injection code litter everywhere in our code base. If we need to refactor down the road, we want it to be as easy as possible.
- Performance - How much overhead does each framework have when creating and injecting objects?
- Ease of use - Is there a large learning curve? Do we have to write mounds of code to get something simple working? We want to have as little configuration as possible.
- Community size - Larger communities usually means that a project will continue to be maintained. We don't want to use a framework and have to fix our own bugs ;) Also any questions we have along the way can (hopefully) be answered by the framework's developer/user community .
- 小代码足迹 - 我所说的小代码足迹是我们不希望在我们的代码库中到处都有依赖注入代码。如果我们需要重构，我们希望它尽可能简单。
- 性能 - 每个框架在创建和注入对象时有多少开销？
- 易于使用 - 是否有很大的学习曲线？我们是否必须编写大量代码才能使一些简单的工作正常工作？我们希望尽可能少的配置。
- 社区规模 - 较大的社区通常意味着项目将继续得到维护。我们不想使用框架，而必须修复我们自己的错误；) 此外，我们在此过程中遇到的任何问题都可以（希望）由框架的开发人员/用户社区回答。
Comparisons of the two frameworks against the listed criteria would be greatly appreciated. Any personal experiences that help to compare the two would also be extremely helpful.
将两个框架与所列标准进行比较将不胜感激。任何有助于比较两者的个人经历也将非常有帮助。
Disclaimer: I'm fairly new to dependency injection so excuse my noob-ness if I asked a question that isn't pertinent to this discussion.
免责声明：我对依赖注入相当陌生，所以如果我问的问题与本次讨论无关，请原谅我的菜鸟。
采纳答案by Jamie McCrindle
You may want to include Spring in your list of Dependency Injection frameworks you are considering. Here are some answers to your questions:
您可能希望将 Spring 包含在您正在考虑的依赖注入框架列表中。以下是您的问题的一些答案：
Coupling to the framework
耦合到框架
Pico- Pico tends to discourage setter injection but other than that, your classes don't need to know about Pico. It's only the wiring that needs to know (true for all DI frameworks).
Pico- Pico 倾向于阻止 setter 注入，但除此之外，您的课程不需要了解 Pico。它只是需要知道的接线（适用于所有 DI 框架）。
Guice- Guice now supports the standard JSR 330annotations, so you do not need Guice specific annotations in your code anymore. Spring also supports these standard annotations. The argument that the Guice guys use is that without a Guice annotation processor running, these shouldn't have an impact if you decide to use a different framework.
Guice- Guice 现在支持标准的JSR 330注释，因此您的代码中不再需要 Guice 特定的注释。Spring 也支持这些标准注解。Guice 人员使用的论点是，如果没有运行 Guice 注释处理器，如果您决定使用不同的框架，这些应该不会产生影响。
Spring- Spring aims to allow you to avoid any mention of the Spring framework in your code. Because they do have a lot of other helpers / utilities etc. the temptation is pretty strong to depend on Spring code, though.
Spring- Spring 旨在让您避免在代码中提及 Spring 框架。因为他们确实有很多其他帮助程序/实用程序等。不过，依赖 Spring 代码的诱惑非常大。
Performance
表现
Pico- I'm not too familiar with the speed characteristics of Pico
Pico- 我不太熟悉 Pico 的速度特性
Guice- Guice was designed to be fast and the comparison mentioned in the reference has some numbers. Certainly if speed is a primary consideration either using Guice or wiring by hand should be considered
Guice- Guice 的设计速度很快，参考文献中提到的比较有一些数字。当然，如果速度是主要考虑因素，则应考虑使用 Guice 或手工布线
Spring- Spring can be slow. There has been work to make it faster and using the JavaConfig library should speed things up.
春天- 春天可能很慢。一直在努力使其更快，使用 JavaConfig 库应该会加快速度。
Ease of use
便于使用
Pico- Simple to configure. Pico can make some autowire decisions for you. Not clear how it scales to very large projects.
Pico- 配置简单。Pico 可以为您做出一些自动装配决定。不清楚它如何扩展到非常大的项目。
Guice- Simple to configure, you just add annotations and inherit from AbstractModule to bind things together. Scales well to large projects as configuration is kept to a minimum.
Guice- 配置简单，您只需添加注释并从 AbstractModule 继承即可将事物绑定在一起。由于配置保持在最低限度，因此可以很好地扩展到大型项目。
Spring- Relatively easy to configure but most examples use Spring XML as the method for configuration. Spring XML files can become very large and complex over time and take time to load. Consider using a mix of Spring and hand cranked Dependency Injection to overcome this.
Spring- 相对容易配置，但大多数示例使用 Spring XML 作为配置方法。随着时间的推移，Spring XML 文件会变得非常大和复杂，并且需要时间来加载。考虑混合使用 Spring 和手动依赖注入来克服这个问题。
Community Size
社区规模
Pico- Small
Pico- 小
Guice- Medium
Guice- 中
Spring- Large
弹簧- 大
Experience
经验
Pico- I haven't had much experience with Pico but it is not a widely used framework so it will be harder finding resources.
Pico- 我对Pico没有太多经验，但它不是一个广泛使用的框架，因此很难找到资源。
Guice- Guice is a popular framework and its focus on speed is welcome when you've got a large project that you're restarting a lot in development. I have a concern about the distributed nature of the configuration i.e. it's not easy to see how our whole application is put together. It's a bit like AOP in this respect.
Guice- Guice 是一个流行的框架，当你有一个大型项目并且在开发中需要大量重启时，它对速度的关注是受欢迎的。我担心配置的分布式特性，即很难看到我们的整个应用程序是如何组合在一起的。这方面有点像AOP。
Spring- Spring is usually my default choice. That said, the XML can become cumbersome and the resulting slowdown annoying. I often end up using a combination of hand crafted Dependency Injection and Spring. When you actually need XML based configuration, Spring XML is quite good. Spring also put a lot of effort into making other frameworks more Dependency Injection friendly which can be useful because they often use best practice when doing so (JMS, ORM, OXM, MVC etc.).
Spring- Spring 通常是我的默认选择。也就是说，XML 可能会变得很麻烦，并且由此产生的速度变慢很烦人。我经常最终使用手工制作的依赖注入和 Spring 的组合。当您真正需要基于 XML 的配置时，Spring XML 非常好。Spring 还付出了很多努力使其他框架对依赖注入更加友好，这很有用，因为它们在这样做时经常使用最佳实践（JMS、ORM、OXM、MVC 等）。
References
参考
回答by Manius
The answer put up by jamie.mccrindle is actually pretty good, but I'm left confused why Spring is the default choice when it's pretty clear that superior alternatives (both Pico and Guice) are available. IMO Spring's popularity has reached it's peak and now it's currently living off the generated hype (along with all the other "me too" Spring sub projects looking to ride the Spring bandwagon).
jamie.mccrindle 给出的答案实际上非常好，但我很困惑为什么 Spring 是默认选择，因为很明显有更好的替代品（Pico 和 Guice）可用。IMO Spring 的受欢迎程度已经达到了顶峰，现在它目前正依靠所产生的炒作（以及所有其他“我也是”Spring 子项目希望赶上 Spring 潮流）。
Spring's only real advantage is community size (and quite frankly, due to the size and complexity, it's needed), but Pico and Guice don't needa huge community because their solution is much cleaner, more organized, and more elegant. Pico seems more flexible than Guice (you can use annotations in Pico, or not--it's extremely efficient). (Edit: Meant to say it's extremely flexible, not that it isn't also efficient.)
Spring 唯一真正的优势是社区规模（坦率地说，由于规模和复杂性，它是需要的），但 Pico 和 Guice不需要庞大的社区，因为他们的解决方案更简洁、更有条理、更优雅。Pico 似乎比 Guice 更灵活（您可以在 Pico 中使用注释，也可以不使用——它非常有效）。 （编辑：意思是说它非常灵活，并不是说它也不高效。）
Pico's tiny size and lack of dependencies is a MAJOR win which shouldn't be understated. How many megs do you need to download to use Spring now? It's a kludgy-mess of huge jar files, with all it's dependencies. Intuitively thinking, such an efficient and "small" solution should scale and perform better than something like Spring. Is Spring's bloat really going to make it scale better? Is this bizarro world? I wouldn't make assumptions that Spring is "more scalable" until that's proven (and explained).
Pico 的小尺寸和缺乏依赖性是一个不容低估的重大胜利。现在需要下载多少兆才能使用 Spring？这是一堆乱七八糟的巨大 jar 文件，以及它的所有依赖项。直观地认为，这样一个高效且“小”的解决方案应该比 Spring 之类的解决方案具有更好的扩展性和性能。Spring 的膨胀真的会使其扩展性更好吗？这是一个奇异的世界吗？在证明（和解释）之前，我不会假设 Spring 是“更具可扩展性”。
Sometimes creating something good (Pico/Guice) and then keeping your HANDS OFF of it instead of adding bloat and kitchen sink features with endless new versions really does work out...
有时创造一些好的东西（Pico/Guice）然后让你的手远离它而不是用无尽的新版本添加膨胀和厨房水槽功能确实有效......
回答by Joshua Davis
NOTE: This is more of a comment/rant than an answer
注意：这更像是评论/咆哮而不是答案
PicoContainer is great. I'd switch back to it if they'd just fix their web sites. It's really confusing now:
PicoContainer 很棒。如果他们只是修复他们的网站，我会切换回它。现在真的很困惑：
- http://picocontainer.comwhich is the most recent, but many pages have formatting issues and a few pages don't work at all. It looks like the pages were auto-converted from the older content.
- http://picocontainer.codehaus.org/Which seems frozen in time at version 2.10.2 - It would be really niceif the pages said something like "hey, you're looking at an old web site!"
- http://docs.codehaus.org/display/PICO/Home- A confluence wiki that documents v 1.x, but it doesn't say that anywhere on the pages!
- http://picocontainer.com这是最新的，但许多页面存在格式问题，有些页面根本无法使用。看起来页面是从旧内容自动转换的。
- http://picocontainer.codehaus.org/在 2.10.2 版本中似乎被时间冻结了 -如果页面上显示类似“嘿，您正在浏览一个旧网站！”之类的内容，那就太好了。
- http://docs.codehaus.org/display/PICO/Home- 记录 v 1.x 的 Confluence wiki，但它没有在页面上的任何地方说明！
I'm using Guice 2.x now, even though it's bigger, and it has fewer features. It was just much easier to find the documentation, and it's user group is very active. However, if the direction of Guice 3 is any indication, it looks like Guice is starting to bloat, just like Spring did way back in the early days.
我现在使用的是 Guice 2.x，尽管它更大，而且功能更少。查找文档要容易得多，而且它的用户组非常活跃。然而，如果 Guice 3 的方向有任何迹象，那么 Guice 似乎开始膨胀，就像 Spring 在早期所做的那样。
Update: I posted a comment to the Pico Container folks and they've made some improvements to the web site. Much better now!
更新：我向 Pico Container 人员发表了评论，他们对网站进行了一些改进。现在好多了！
回答by Archimedes Trajano
Although I do like PicoContainer for it's simplicity and it's lack of dependencies. I would recommend using CDI instead because it is part of the Java EE standard so you have no vendor lock-in.
虽然我确实喜欢 PicoContainer，因为它很简单，而且没有依赖性。我建议改用 CDI，因为它是 Java EE 标准的一部分，因此您没有供应商锁定。
In terms of intrusiveness, it's main problem is the requirement of a container and the use of a relatively empty META-INF/beans.xml file (needed to indicate that the jar is using CDI) and the use of annotations (though they are standard)
在侵入性方面，它的主要问题是容器的要求和使用相对空的 META-INF/beans.xml 文件（需要表明 jar 使用 CDI）和使用注释（虽然它们是标准的） )
The lightweight CDI container I use for my own projects is Apache Open Web Beans. Though it took a while to figure out how to create a simple app (unlike Pico) which looks like this.
我用于我自己的项目的轻量级 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();
}
回答by A.C.Andreani
It is a old question but today you can consider Dagger (https://github.com/square/dagger) in your Android App project. Dagger does code generation on compilation time. So you get a shorter startup time and less memory usage on execution time.
这是一个老问题，但今天您可以在您的 Android 应用程序项目中考虑 Dagger ( https://github.com/square/dagger)。Dagger 在编译时生成代码。因此，您可以获得更短的启动时间和更少的执行时间内存使用量。
