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.