Пример, который вы привели, выглядит так, как будто он относится к уровню обслуживания трехуровневой архитектуры .
То есть у вас будет ContentService
, который предоставляет такие методы, как findAll()
. Тогда ваш ContentController
вызовет этот метод в соответствующее время и поместит полученный List<Content>
в модель, которую затем (наконец!) Может использовать представление.
Вот как я бы написал вашу реализацию ContentService
(при условии, что интерфейс ContentService
уже определен):
public class ContentServiceImpl implements ContentService {
@Autowired
private EntityManager em; // Gets wired in by Spring
public List<Content> findAllContent() {
return em.createNamedQuery("Content.findAll").getResultList();
}
...
}
Я знаю, что это похоже на большую работу по сравнению с тем, что вы пытались (прямой доступ к именованному запросу "на" объекте из представления), но это довольно серьезное нарушение разделения проблем , которая является основной идеей шаблона MVC , который каждый сегодня использует.
Подумайте о том, что произойдет, если вам скажут, что findAll
должен на самом деле найти только 1027 * объектов с новым установленным флагом visible
true
. При вашем текущем подходе (если он даже работал) вам придется изменить представление - когда изменение должно быть выделено на гораздо более низкий уровень.
Теперь подумайте о том, что нужно сделать с помощью описанной выше реализации. Напишите новый @NamedQuery
для вашего Content
объекта, а затем вызовите , что в методе findAllContent()
. Больше ничего не меняется.