JSF managed bean naming conventions

Question

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.

Answer 1

There is no strict convention specified by JSF itself. I've seen the following conventions:

• FooBean
• FooBacking
• FooManager
• FooController
• FooManagedBean

Or even just Foo which is then placed in a specific package like com.example.controller, com.example.backing or even com.example.view, etc.

I myself tend to use FooManager for application and session scoped beans (e.g. DataManager, UserManager, LocaleManager, etc) and just Foo, or as mandated by my current project, FooBacking (e.g. Login or LoginBacking) for request and view scoped beans, which are each usually tied to a specific <h:form> and/or view.

FooBean is too vague. Really a lot of classes can be marked as javabeans. JSF managed beans, JPA entities, EJBs, data transfer objects, value objects, etc. The Bean naming does not indicate the real responsibility of the class in any way. True, I use often public class Bean or MyBean in my generic code examples in blogs or forum/Q&A answers, but in real world you should avoid that.

FooManagedBean is 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 a FooBackingBean is technically more correct, but it's still too long and the Bean part 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.