1

我正在阅读 JavaEE 6 教程，在阅读 SessionBean 和 CDI 部分时，我遇到了一些疑问。

1）据我所知，@EJB注释注入了一个 SessionBean 导致使用依赖注入模式。我知道这种模式旨在扭转谁构建什么对象的责任。因此，不是某个类创建它拥有依赖项，而是将在构造函数中接收它们。然而，@EJB注解如何缓解不注入依赖的问题呢？@Inject注释也是如此。

2）我有这个实用程序类（仅包含静态方法），它将日期格式化为多种格式（yyyy-MM-dd、dd-MM-yyyy 等...）。对这些方法使用无状态会话 Bean 更好还是应该保留 Utility 类？@Inject如果为此使用 EJB，使用它或使用注解使用 bean 有什么区别？

3) 使用依赖注入时，使用服务定位器或工厂模式有意义吗？（尽管我已经看到服务定位器被记录为反模式）。

4

2 回答 2

2

@EJB 和 @Inject 缓解了不注入的问题，通过...注入（duh！;)）

将此实用程序方法保留在这些类中。EJB 用于事务管理、资源使用限制、基于用户角色限制对方法的访问等。这些对于您的实用程序方法似乎都不是必需的。

您最多可以通过 CDI 使该实用程序类可注入：为它定义一个接口并创建一个生产者方法。通常，即使这样也有些过分了，但这取决于您的类的确切扩展及其用法。

通过注入，您仍然可以拥有工厂（生产者是工厂的一种），但客户端没有明确使用工厂。客户端声明一个依赖，CDI 可以使用“工厂”（生产者）来满足这一点。

于 2013-04-14T15:05:32.803 回答
1

  1. 不，依赖注入不仅仅是为了避免创建它的依赖。这也是为了避免向容器询问其依赖项。容器不是向容器询问依赖项，而是将依赖项注入到组件中。我不明白您所说的“不注入依赖项的问题”是什么意思。请说清楚。

  2. 当您需要由容器围绕方法添加事务性、安全性和/或远程处理方面时，通常会使用会话 bean。如果它只是一个实用程序类，则没有理由将其设为会话 bean。

  3. 不，这没有意义。依赖注入的主要目标是替换服务定位器和/或工厂的使用，以便让容器将依赖项注入 bean。这就是使代码易于测试的原因，因为您可以在单元测试中简单地将虚假依赖项（模拟对象）注入到 bean 中。

于 2013-04-14T15:05:22.937 回答