Именование классов jsf как myClassBean.java, когда класс связан с пользовательским интерфейсом [duplicate]

Не существует строгого соглашения, определенного самим JSF. Я видел следующие соглашения:

• FooBean
• FooBacking
• FooManager
• FooController
• FooManagedBean

Или даже просто Foo, который затем помещается в определенный пакет, такой как com.example.controller, com.example.backing или даже com.example.view, и т. д.

Я сам, как правило, использую FooManager для бранд-приложений и сеансов (например, DataManager, UserManager, LocaleManager и т. д.) и только Foo, или как это предусмотрено моим текущий проект FooBacking (например, Login или LoginBacking) для запроса и просмотра облачных объектов, которые обычно привязаны к конкретному <h:form> и / или виду.

FooBean слишком расплывчатым. Действительно, многие классы могут быть отмечены как javabeans. Управляемые JSF компоненты, объекты JPA, EJB, объекты передачи данных, объекты ценности и т. Д. Именование Bean не указывает на реальную ответственность класса каким-либо образом. Правда, я часто использую public class Bean или MyBean в моих примерах общего кода в блогах или форумах / Q & amp; Ответы, но в реальном мире вам следует избегать этого.

FooManagedBean - это плохое имя IMO, оно не только слишком длинное и уродливое, но технически управляемый bean-компонент является экземпляром бэкбона, который управляется некоторой структурой (JSF в этом случае). Само определение класса действительно является бэк-компонентом, а не управляемым компонентом . Таким образом, FooBackingBean технически более правилен, но он все еще слишком длинный, а часть Bean немного зудящая.

Во всяком случае, это довольно субъективный вопрос, на который вряд ли можно ответить объективно с The One И правильный ответ. Для меня или для кого-то еще не важно, что вы делаете, если вы согласны с этим на протяжении всего проекта.