何时需要显式命名托管Bean?

4
在我对创建托管bean进行的所有研究中,我没有注意到(或可能是我忽略了)何时使用显式命名bean,例如@Named(name = "someBean")
我想我难以理解的是,为什么除了类名之外,您还想将bean命名为其他任何内容:
@Named(name = "someBean")
public class SomeBean implements Serializebale {
}

我看过的所有示例中,有些使用显式名称,而有些只是使用@Named来保留默认类名。然而,这些示例中没有任何一个解释为什么要使用显式命名。相比于其他名称,尝试使用其他方式访问Bean更加混乱。

所以,我的问题是,是否有一些规则或约定,需要提供与您的类名不同的访问名称,或者人们只是在有长类名需要进行较少的键入时才这样做?


1
你的问题相当于为什么有人会用绰号称呼你。也许公司政策规定所有bean必须以CompanyServiceBean结尾,而你认为这会使事情变得混乱。也许这个bean的命名不好,但你不能重命名它,所以你可以在这里指定一个更好的名称来使用。其实并不重要。你可以给bean命名,但不是必须的。 - Kayaman
那基本上回答了我的问题。 - Paul Samsotha
1个回答

6
你的问题涉及约定优于配置设计范式。为了解决过去出现的错误,其中包括对广泛配置的需求,自上次发布以来许多Java框架/API等都引入了很多默认值。在这种情况下,JSF/CDI也不例外。
例如,只需使用@ManagedBean注释一个bean,就足以让它成为@RequestScoped并通过simpleClassName在EL范围内可用:
name()属性的值被视为托管bean名称。如果未指定name属性的值或为空字符串,则从完全限定类名的未限定类名部分并将第一个字符转换为小写来派生托管bean名称。例如,如果ManagedBean注释位于具有完全限定类名com.example.Bean的类上,并且注释中没有name属性,则将托管bean名称视为bean。附加此注释的类的完全限定类名被视为托管bean类。
使用NoneScoped、RequestScoped、ViewScoped、SessionScoped、ApplicationScoped或CustomScoped注释之一声明托管bean的范围。如果省略作用域注释,则必须将bean处理为存在RequestScoped注释的情况。
同样适用于CDI bean、EJB、JPA实体类等。因此,我认为放置@ManagedBean(name = "myBean") public class MyBean类型的行的唯一原因是为自己或不熟练的受众明确重复托管bean的生成名称。
值得注意的是,开发人员有时候会将bean命名为其类的简单名称,但也会使用一些明确且自我解释的短名称,例如以下代码行:@ManagedBean(name = "settings") public class UserDefinedSettingsBean

@Named 也可以用作一个限定词,但我认为这样的解决方案相当丑陋。 - Karl Kildén

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接