19

我喜欢 Guice 让手动创建自己的模块变得相当简单的方式，每个模块都有自己的代码绑定。另一方面，CDI 似乎更多地依赖魔术而不是对 sest 绑定的编程访问。我错了吗，或者如何使用 WELD 达到相同的效果。

任何代码示例将不胜感激...

澄清

我希望使用 Guice 在http://code.google.com/p/google-guice/上给出的构建器模式样式以编程方式构建一个模块（Guice 术语对不起我不确定 CDI 术语）。

我正在构建一个动态系统，我需要能够绑定类型（如接口）、常量等，而不仅仅是让 Weld 动态扫描类路径等并查找和注册类型。我相信 CDI 是静态的 javax.inject 包不包含任何允许以编程方式将类型绑定到实现的接口。

澄清第 2 部分

原始问题的基本前提是简单的观察，即注释已被烘焙，并且其中定义的用于帮助注入器的规则无法更改。我最初希望公共访问与 CDI 类路径扫描器用于为其内部使用构建定义的相同接口。基本上我说的是，我想要一个允许我阅读注释并为容器创建定义的层。默认提供者可能是现在发生的事情，但是如果您想要其他策略，那么就有可能做到这一点。

当前方法的一个问题是不能重用具有不同注释的组件（类）来选择不同的协作者。在你跳之前，让我限定这个陈述，是的，它可以通过提供者等来完成，但这会导致更多的工件。应该有更简单的方法。

示例 1

对不起，如果这个例子很糟糕，我的用例会涉及更多，细节会妨碍阅读时间。

想象一下，有一个 url 重写组件，为了参数，它有一些参数，比如

  • 用那个模式替换这个模式。
  • 也许是一个 html 清洁器

如果您希望使用两个不同的替换规则注入相同的组件，但有 html 清洁器注入器，那么您就卡住了。当然有办法解决这个问题，但它们需要人工制品，这当然是更多的代码。

不幸的是，所有绑定规则都在类上而不是实例上，因此每次你请求一个类时，你都会得到一个功能上相当的实例。

焊接

这个问题是很久以前写的，我已经放弃了 Weld。我相信它决定其魔法的方式是错误的。我不喜欢他们在没有为我提供控制何时或如何重复此操作的方法的情况下向我指示这是如何发生的事实。我不喜欢这种不灵活。

4

1 回答 1

8

我定期使用 Guice 和 CDI/Seam2。简短的回答是否定的，CDI 不支持编程 bean 定义（Guice 称之为“绑定”）。

CDI 使用声明性方法，容器将自动扫描 bean 定义。这可以在某种程度上使用“替代”功能进行定制，但它不像 Guice 的程序化方法那样灵活（您基本上可以做任何事情）。

我的两分钱

我使用这两个框架：Guice 用于“较低级别”的非企业 POJO 组件（我没有/不需要 CDI 功能），CDI 用于我需要 CDI 的额外功能的任何东西，插入 JSF 或 EJB3 的东西。主要是我开始使用 Guice 作为在“适配器”JVM 中获取 DI 的一种方式，这些 JVM 在应用程序服务器集群之外运行。随着我对 CDI 越来越熟悉，我发现对 Guice 的需求越来越少。我想象当 CDI 支持“非托管”实例时，我可能能够用 CDI 替换 Guice（例如，weld-se）。

RE：焊接“魔术”——IMO 没有什么是关于 bean 定义扫描的“魔术”。它在 CDI 规范中定义得非常好，它类似于其他 Java Enterprise 框架，例如 JPA 和 EJB3。

我给你的建议是：

  1. 使用对你有用的东西。如果您不喜欢 CDI，请不要使用它。例如，我需要在我的应用程序中使用“非托管实例”，因此我使用 Guice。
  2. 如果您认为 CDI 可能会更好（我愿意），请参与进来 - 参与定义 CDI 的社区。
于 2011-07-28T12:17:19.200 回答