与 @Named 一起揭开挑战

golang学习网今天将给大家带来《与 @Named 一起揭开挑战》，感兴趣的朋友请继续看下去吧！以下内容将会涉及到等等知识点，如果你是正在学习文章或者已经是大佬级别了，都非常欢迎也希望大家都能给我建议评论哈~希望能帮助到大家！

在上下文和依赖注入 (cdi) 不断发展的环境中，开发人员经常遇到与 bean 命名、默认实现和潜在冲突相关的障碍。本文详细探讨了 cdi 中与 @named 注释相关的潜在陷阱。我们将深入研究其复杂性，阐明有问题的场景，并讨论替代方法，包括使用 smallrye 中的 @identifier。此外，我们将提供有关构建健壮且可维护的jakarta ee
最佳实践的见解 应用程序。

理解@default

@default 注释是 cdi 中的一个有价值的工具，用于将特定实现显式标记为给定接口或 bean 类型的默认实现。它在处理同一接口的多个实现时发挥作用，允许开发人员指定在不使用其他限定符时默认应注入哪个实现。

考虑存在 greetingservice 接口的多个实现的场景：

@default
public class defaultgreetingservice implements greetingservice {

  @override
  public string greet(string name) {
    return "hello, " + name;
  }
}

public class specialgreetingservice implements greetingservice {

  @override
  public string greet(string name) {
    return "greetings, " + name + "!";
  }
}

在不指定任何限定符的情况下注入 bean 时，cdi 使用 @default 标记的 bean 作为默认值。这在具有多种实现的场景中非常有用，提供了明确的默认选择。

@inject
private greetingservice greetingservice; // injects the @default implementation

虽然 @default 的使用是可选的，但强烈建议使用它，特别是在处理具有多个实现的接口时。它提供了清晰一致的默认选项，防止 bean 注入期间出现歧义和意外行为。

探索@named——一把双刃剑

@named 限定符在 cdi 中发挥着基础作用，为 bean 分配一个人类可读的名称或标识符。开发人员在将 bean 注入其他组件时经常使用它来通过名称引用 bean。

但是，@named 也有其自身的一系列挑战，特别是在没有额外限定符的情况下使用时。默认情况下，cdi 将非限定类名关联为 bean 名称。这可能会导致与 @default 限定符发生冲突，从而导致 bean 注入期间出现意外行为。

@named
public class mybean {
  // implementation
}

在没有显式限定符的情况下注入 mybean 时，cdi 将仅添加 @named 限定符，而不是 @default 限定符。仅当在 bean 或其限定符上显式指定 @default 限定符时，才会应用 @default 限定符。

@inject
private mybean mybean;

在这种情况下，如果有其他具有相同类型名称的 bean，可能会出现歧义。例如，如果有另一个名为 mybean 的 bean，则注入将导致歧义。

为了解决这个问题，开发人员应该明确限定他们打算注入的 bean。

@inject
@named("mybean")
private mybean mybean;

或者，开发人员可以为每个 bean 使用自定义限定符来消除歧义。

问题案例：含糊不清和意外违约

当在没有附加限定符的情况下使用 @named 时，会出现歧义，并且存在相同类型的多个实现。考虑以下场景：

@named
public class servicea implements service {
  // implementation
}

@named
public class serviceb implements service {
  // implementation
}

在没有显式限定符的情况下注入 service 可能会导致歧义，因为两个 bean 按类型匹配，并且没有名称或限定符区分它们。

@inject
private service service;

在这种情况下，cdi 不会隐式添加 @default 或尝试解决歧义，从而导致由于不明确的依赖关系而导致注入失败。

替代方案：从 smallrye common 引入 @identifier

认识到 @named 带来的挑战，开发人员经常寻求替代方案来更明确地控制 bean 识别。其中一种替代方案是来自
的 @identifier 注释 小黑麦常见。此注释提供了一种更清晰、更可控的 bean 命名方法，减少了冲突和意外默认的风险。与 @named 不同，@named 要求每个应用程序都有唯一的值，@identifier 允许多个 bean 具有相同的标识符值，只要它们的类型不同。在处理相同接口或相关类型的不同实现时，这种灵活性特别有用。

要使用@identifier，只需用该注解注释bean类并指定标识符值即可：

@identifier("payment")
public class defaultpaymentprocessor implements paymentprocessor {
  // implementation
}

@identifier("payment")
public class legacypaymentgateway implements paymentgateway {
  // implementation
}

使用@identifier注入bean很简单：

public class client {
  @inject
  @identifier("payment")
  paymentprocessor processor;

  @inject
  @identifier("payment")
  paymentgateway gateway;

}

这里，“付款”@identifier 值被多个 bean 重用，因为 paymentprocessor 和 paymentgateway 的类型不同。 @named 不允许这种灵活性，其中
值在应用程序范围内必须是唯一的。

@named 的另一种替代方法是创建自定义限定符。自定义限定符是用户定义的注释，可用于识别和限定 bean。它们提供对 bean 选择的最精细控制，并且可以根据应用程序的特定需求进行定制。

要创建自定义限定符，请按照以下步骤操作：

1. 定义一个新的注释类。
2. 使用@qualifier对注解类进行注解。
3. （可选）为限定符提供默认值。

例如，以下名为 defaultpaymentgateway 的自定义限定符表示默认支付网关实现：

@qualifier
@retention(runtime)
@target({method, field, parameter, type})
public @interface defaultpaymentgateway {

}

要使用自定义限定符，请用它注释 bean 类：

@defaultpaymentgateway
public class standardpaymentgateway implements paymentgateway {
  // implementation
}

public class expresspaymentgateway implements paymentgateway {
  // implementation
}

然后，使用限定符注入 bean：

@Inject
@DefaultPaymentGateway
private PaymentGateway paymentGateway;

选择正确的方法

bean 识别的最佳方法取决于应用程序的具体需求。对于简单的应用程序，@named 可能就足够了。对于更复杂的应用程序，@identifier 或
自定义限定符提供更多控制和灵活性。

下表总结了每种方法的优缺点：

进一步确认，可以参考官方cdi规范

结论：bean 命名和默认值的策略选择

总之，与 @named 相关的潜在陷阱强调了在 cdi 中使用此注释时需要仔细考虑。当依赖隐式命名时，尤其是在存在多个实现的情况下，可能会出现歧义和意外的默认值。鼓励开发人员探索替代方案，例如来自smallrye common的@identifier，以获得更受控制和更明确的bean识别方法。采用显式限定、自定义限定符和替代方法可确保更流畅、更可控的 cdi 体验，从而实现健壮且可维护的 java。

好了，本文到此结束，带大家了解了《与 @Named 一起揭开挑战》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！