Я разрабатывал свое первое приложение Java EE, в котором есть несколько классов сущностей JPA, каждый из которых имеет соответствующий класс EJB для работы с бизнес-логикой. Что я сделал, так это изменил один из этих bean-компонентов с Stateless на SessionScoped, поэтому я могу использовать его, чтобы позволить пользователю работать с рядом полей формы, все из которых отображаются в форме JSF.
Однако я начинаю думать, что это явно неправильно, так как я делаю такие вещи, как реализация таких методов, как "submitStep1" и "goBackToStep2" в моем EJB. Эти методы устанавливают индикаторы, которые используются элементами рендеринга различных тегов на странице JSF, поэтому они явно являются «логикой представления».
Мой вопрос в том, как мне реструктурировать мой код? Я думаю, что у меня должен быть только один компонент SessionScoped (или он должен иметь состояние?), который имеет дело с логикой представления моей страницы JSF и может использовать все остальные ejbs (и, соответственно, мои классы JPA). Этот bean-компонент будет находиться на уровне уровня представления моего приложения, что означает, что моему уровню бизнес-логики не потребуются никакие сеансовые Bean-компоненты с областью действия сеанса.
Теперь все это имеет смысл для меня, и это то, что я, вероятно, собираюсь сделать. Однако причина моего вопроса заключается в том, что на моих страницах JSF xhtml я часто использую теги JSF EL для ссылки на содержимое EJB. Есть ли какие-либо подводные камни, связанные с JPA, которых мне нужно остерегаться при написании классов уровня представления?
Я знаю, что мой вопрос довольно расплывчатый и не связан с конкретным примером. И хотя я довольно много узнал о bean-компонентах Stateful v Stateless на этом и других сайтах, я просто хочу знать, что предполагаемая структура является лучшей.
