4

通过我对创建托管 bean 所做的所有研究，我没有注意到（或者我可能忽略的）是何时使用 bean 的显式命名，例如@Named(name = "someBean").

我想我很难理解的是为什么你想给 bean 命名而不是你的类名：

@Named(name = "someBean")
public class SomeBean implements Serializebale {
}

在我见过的所有示例中，有些使用显式名称，有些只是使用@Named保留默认类名。这些例子都没有解释为什么他们使用显式命名。尝试使用类名以外的任何内容访问 bean 似乎更令人困惑。

所以我想问题是，是否有任何经验法则或约定来说明您何时想要提供与您的类名不同的访问名，或者如果人们希望能够提供一个长类名，他们是否会这样做输入更少的访问权限？

4

1 回答 1

6

您的问题是关于配置设计范式的约定。为了与过去的错误作斗争，其中包括大量配置的必要性，自许多 Java 框架/API 等的最新版本以来，已经引入了许多默认值。JSF/CDI 在这种情况下也不例外。

例如，通过以下方式注释一个 bean并@ManagedBean让它@RequestScoped在 EL 范围内可用就足够了simpleClassName：

name() 属性的值被视为 managed-bean-name。如果 name 属性的值未指定或为空字符串，则 managed-bean-name 派生自完全限定类名的非限定类名部分并将第一个字符转换为小写。例如，如果 ManagedBean 注解在具有完全限定类名称 com.example.Bean 的类上，并且注解上没有 name 属性，则 managed-bean-name 将被视为 bean。此注释所附加到的类的完全限定类名被视为 managed-bean-class。

使用 NoneScoped、RequestScoped、ViewScoped、SessionScoped、ApplicationScoped 或 CustomScoped 注释之一声明托管 bean 的范围。如果省略范围注释，则必须像存在 RequestScoped 注释一样处理 bean。

这同样适用于 CDI bean、EJB、JPA 实体类等。所以，我看到放置类型行的唯一原因@ManagedBean(name = "myBean") public class MyBean是为您自己或没有经验的观众显式地重复生成的托管 bean 的名称。

还值得注意的是，有时开发人员倾向于不在其类的简单名称之后命名 bean，而是参考一些明确的简短自解释名称，如以下行：@ManagedBean(name = "settings") public class UserDefinedSettingsBean.

于 2013-10-03T07:01:21.137 回答