你什么时候应该明确地命名一个Managed Bean？ [英] When should you explicity name a Managed Bean?

问题描述

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

With all the research I've done on creating managed beans, what I've not noticed (or what I may have overlooked) is when to use explicit naming of the bean e.g. @Named(name = "someBean").

我想我很难理解为什么你想要将豆子命名为除了你的班级名称之外的其他东西：

I guess what it hard for me to understand is why you would want to name the bean anything other than your class name:

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

通过我看到的所有示例，有些使用显式名称，有些只使用 @Named 保留默认的类名。这些例子没有解释为什么他们使用显式命名。尝试使用除类名之外的任何东西来访问bean似乎更令人困惑。

With all the examples I've seen, some use the the explicit name and some just use @Named to leave the default class name. What none of these examples explained was why they used the explicit naming. It just seems more confusing to try and access the bean with anything other than the class name.

所以我想问题是，是否有任何经验法则或惯例当你想要提供一个与你的类名不同的访问名时，或者如果他们有一个他们希望能够以更少的输入访问的长类名，那么人们是否只是这样做？

So I guess question is, is there any rule of thumb or convention as to when you would want provide an access name different from your class name, or do people just do it if they have a long class name that they want to be able to access with less typing?

推荐答案

您的问题是关于 约定优于配置 设计范例。为了应对过去的错误，以及其他有关广泛配置的必要性，自许多Java框架/ API等的最新版本以来已经引入了许多默认值。在这种情况下，JSF / CDI也不例外。

Your question regards the Convention over configuration design paradigm. To fight with mistakes from the past that among others concerned necessity for extensive configuration, many defaults have been introduced since the last releases of many Java frameworks/APIs, etc. JSF/CDI is no exception in this case.

例如，使用 @ManagedBean 让它为 @RequestScoped 并让它在EL范围 simpleClassName ：

For example, it's enough to annotate a bean with @ManagedBean to let it be @RequestScoped and let it be available in EL scope by simpleClassName:

取name（）属性的值成为托管bean名称。如果未指定name属性的值或者为空String，则从获取完全限定类名的非限定类名部分并将第一个字符转换为小写来派生managed-bean-name。例如，如果ManagedBean批注位于具有完全限定类名com.example.Bean的类上，并且批注上没有name属性，则managed-bean-name将被视为bean。附加此批注的类的完全限定类名称将被视为托管bean类。

The value of the name() attribute is taken to be the managed-bean-name. If the value of the name attribute is unspecified or is the empty String, the managed-bean-name is derived from taking the unqualified class name portion of the fully qualified class name and converting the first character to lower case. For example, if the ManagedBean annotation is on a class with the fully qualified class name com.example.Bean, and there is no name attribute on the annotation, the managed-bean-name is taken to be bean. The fully qualified class name of the class to which this annotation is attached is taken to be the managed-bean-class.

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

The scope of the managed bean is declared using one of NoneScoped, RequestScoped, ViewScoped, SessionScoped, ApplicationScoped, or CustomScoped annotations. If the scope annotations are omitted, the bean must be handled as if the RequestScoped annotation is present.

这同样适用于CDI bean， EJB，JPA实体类等等。因此，我看到将类型 @ManagedBean（name =myBean）公共类MyBean 的行放入的唯一原因是明确重复为自己或无经验的受众生成托管bean的生成名称。

The same applies to CDI beans, EJBs, JPA Entity classes, etc. So, the only reason I see to put lines of the type @ManagedBean(name = "myBean") public class MyBean is to explicitly repeat the generated name of the managed bean either for yourself, or for the unexperienced audience.

值得注意的是，开发人员不时会将bean命名为它的类的简单名称，但请参考一些明确的简短自解释名称，如下所示： @ManagedBean（name =settings）public class UserDefinedSettingsBean 。

It is also worth noting that from time to time developers tend to name the bean not after the simple name of its class, but refer to some explicit short self-explaining names like in the following line: @ManagedBean(name = "settings") public class UserDefinedSettingsBean.

这篇关于你什么时候应该明确地命名一个Managed Bean？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！