JSF 托管 Bean 命名约定
这些天我曾经使用 JSF，但有一个“约定”我不确定是否应该使用。在使用托管 Bean 时，人们通常将其命名为 XxxxxManagedBean，其中前缀可以是与您的业务相关的任何名称。
你也这样工作过吗？特别是，尽管搜索很容易，但我不太喜欢。您正在使用其他约定吗？
感谢您回答这个简单的疑问。
These days I used to work with JSF, but there's a "convention" I'm in doubt if I should use. While working with managed beans, people used to name it as XxxxxManagedBean where the prefix can be any name related to your business.
Have you worked like that? Particularly, I don't like that much despite makes search easy. Are you using another convention?
Thanks for answering this simple doubt.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
JSF 本身没有指定严格的约定。我见过以下约定：
FooBeanFooBackingFooManagerFooControllerFooManagedBean甚至只是
Foo，然后将其放置在特定的包中，例如com.example.controller、com.example.backing甚至com. example.view等我自己倾向于使用
FooManager用于应用程序和会话范围的 bean（例如DataManager、UserManager、LocaleManager等）以及Foo，或者按照我当前项目的要求，FooBacking（例如Login或LoginBacking）用于请求和查看作用域bean，这每个通常都与特定的FooBean太模糊了。确实有很多类可以标记为 javabean。 JSF 托管 Bean、JPA 实体、EJB、数据传输对象、值对象等。Bean命名并不以任何方式表明该类的真正职责。确实，我经常public class Bean或MyBean在博客或论坛/问答答案中的通用代码示例中，但在现实世界中您应该避免这样做。FooManagedBean在我看来是一个糟糕的名字，它不仅太长而且丑陋，而且从技术上讲，托管 bean 是由某个框架（JSF）管理的支持 bean 的实例在这种情况下）。 类定义本身实际上是一个支持bean，而不是托管bean 。因此，FooBackingBean在技术上更正确，但它仍然太长，而且Bean部分有点痒。无论如何，这是一个相当主观的问题，很难用唯一正确的答案来客观地回答。对于我或其他任何人来说，你如何看待它并不重要，只要你在整个项目中保持一致即可。
There is no strict convention specified by JSF itself. I've seen the following conventions:
FooBeanFooBackingFooManagerFooControllerFooManagedBeanOr even just
Foowhich is then placed in a specific package likecom.example.controller,com.example.backingor evencom.example.view, etc.I myself tend to use
FooManagerfor application and session scoped beans (e.g.DataManager,UserManager,LocaleManager, etc) and justFoo, or as mandated by my current project,FooBacking(e.g.LoginorLoginBacking) for request and view scoped beans, which are each usually tied to a specific<h:form>and/or view.FooBeanis too vague. Really a lot of classes can be marked as javabeans. JSF managed beans, JPA entities, EJBs, data transfer objects, value objects, etc. TheBeannaming does not indicate the real responsibility of the class in any way. True, I use oftenpublic class BeanorMyBeanin my generic code examples in blogs or forum/Q&A answers, but in real world you should avoid that.FooManagedBeanis IMO a poor name, it's not only too long and ugly, but technically, a managed bean is an instance of a backing bean which is managed by some framework (JSF in this case). The class definition itself is really a backing bean, not a managed bean. So aFooBackingBeanis technically more correct, but it's still too long and theBeanpart is a bit itchy.Anyway, this is a pretty subjective question which can hardly be answered objectively with The One And Correct answer. It really doesn't matter that much to me or anyone else what you makes of it, as long as you're consistent with it throughout the entire project.