Ответ 1
Это правильный способ сделать что-то?
Помимо выполнения бизнес-логики неэффективный способ использования управляемого метода bean и использование слишком широкой управляемой области bean, это выглядит хорошо. Если вы переместите вызов службы из метода getter методу @PostConstruct и используйте @RequestScoped или @ViewScoped вместо @SessionScoped, он будет выглядеть лучше.
См. также:
Правильно ли моя терминология?
Все в порядке. Пока вы согласны с этим, и код читается разумным образом. Только ваш способ именования классов и переменных несколько неудобен (нелогично и/или дублирование). Например, я использовал users вместо userList и использовал var="user" вместо var="u" и использовал id и name вместо userId и userName. Кроме того, "UserListService" звучит так, что он может обрабатывать только списки пользователей, а не пользователей в целом. Я бы предпочел использовать "UserService", чтобы вы также могли использовать его для создания, обновления и удаления пользователей.
См. также:
"Служба" больше похожа на DAO?
Это не совсем DAO. В принципе, JPA является настоящим DAO здесь. Раньше, когда JPA не существовало, все домашние интерфейсы DAO, так что методы обслуживания могут продолжать использовать их, даже когда базовая реализация ( "простой старый" JDBC или "старый добрый" Hibernate и т.д.) Изменяется. Реальная задача метода сервиса - прозрачное управление транзакциями. Это не ответственность DAO.
См. также:
- Я обнаружил, что JPA, или, похоже, не поощряет шаблон DAO
- Отношение DAO и JDBC?
- Когда необходимо или удобно использовать Spring или EJB3 или все вместе?
И диспетчер чувствует, что выполняет некоторую работу службы.
Я могу представить, что он делает это в этой относительно простой установке. Однако контроллер фактически является частью интерфейса, а не бэкэнд. Служба является частью бэкэнд, которая должна быть сконструирована таким образом, что она может использоваться повторно во всех разных интерфейсах, таких как JSF, JAX-RS, "простой" JSP + сервлет, даже Swing и т.д. Кроме того, контроллер, специфичный для интерфейса ( также называемый "поддержка bean" или "презентатор" ) позволяет вам иметь дело с конкретным интерфейсом с успехом и/или исключительными результатами, например, в случае JSF, отображающем сообщение лиц в случае исключения из службы.
См. также:
В целом, правильный подход будет выглядеть следующим образом:
<h:dataTable value="#{userBacking.users}" var="user">
<h:column>#{user.id}</h:column>
<h:column>#{user.name}</h:column>
</h:dataTable>
@Named
@RequestScoped // Use @ViewScoped once you bring in ajax (e.g. CRUD)
public class UserBacking {
private List<User> users;
@EJB
private UserService userService;
@PostConstruct
public void init() {
users = userService.listAll();
}
public List<User> getUsers() {
return users;
}
}
@Stateless
public class UserService {
@PersistenceContext
private EntityManager em;
public List<User> listAll() {
return em.createQuery("SELECT u FROM User u", User.class).getResultList();
}
}
Здесь вы можете найти настоящий проект для запуска в реальном мире, используя канонические методы Java EE/JSF/CDI/EJB/JPA: Java EE kickoff app.
См. также:
- Создание страниц главной страницы для сущностей, как их связать и какую область bean выбрать
- Передача управляемого jSF2 pojo bean в EJB или помещение того, что требуется в объект передачи
- Фильтр не инициализирует EntityManager
- javax.persistence.TransactionRequiredException в небольшом приложении facelet