Архитектура JSF-SPRING-HIBERNATE - передовая практика, связанная с бином

Question

Я занимаюсь разработкой веб-проекта, и после долгих исследований я решил использовать JSF+Primefaces, Spring и Hibernate. При разработке архитектуры моего проекта я доработал следующий подход:

Actor -> JSF+ страница PrimeFaces --- > Backing Bean -> Служебный компонент - > Dao -> Hibernate

• Service Bean и DAO - это пружинные бины с внедрением зависимостей.

Теперь моя проблема связана с компонентом поддержки: я планирую использовать несколько компонентов поддержки для страницы пользовательского интерфейса в зависимости от типа страницы, которую мне нужно отобразить.

Теперь, например: для новой страницы регистрации пользователя у меня есть UserProfile.xhtml, который использует UserBackingBean. UserBackingBean имеет UserServiceBean, внедренный весной. UserServiceBean имеет UserDao, введенный Spring.

Теперь в UserBackingBean, когда пользователь вводит данные формы из UserProfile.xhtml, мне нужно будет заполнить объект домена User.java (ORM).

а) Какова лучшая практика для этого? Должен ли я инициализировать User.java в конструкторе на UserBackingBean? Это правильный подход? Подскажите пожалуйста, есть ли другой выход?

б) Также, пожалуйста, предложите вышеупомянутую архитектуру, которую я выбрал для своего проекта? Это правильный подход?

Answer 1

Общее правило, которому я следую, заключается в том, что границы транзакций отмечены в служебных компонентах, поэтому я не люблю изменять спящий режим POJO вне службы, потому что я не знаю, есть ли уже запущенная транзакция. Таким образом, из компонента поддержки я бы назвал передачу служебного уровня в параметры, необходимые служебному уровню для создания гибернации pojo и сохранения ее, обновления и т. Д.

Другой способ сделать это состоит в том, чтобы ваш компонент поддержки реализовал интерфейс, определенный на уровне обслуживания, а затем передал компонент поддержки на уровень обслуживания. Например.

public interface UserInfoRequest {
     public String getName();
}


@Service
public class SomeSpringService {

   @Transactional(.....) 
   public void registerNewUser(UserInfoRequest request)
   {

   }

}

public class SomeBackingBean implements UserInfoRequest {

    private SomeService someSpringService; 

    public void someMethodBoundToSJF()
    {
         this.someSpringService.registerNewUser(this); 
    }
} 

Что касается вашего последнего вопроса, я не фанат JSF, я думаю, что JSF в корне ошибочен, потому что это основанная на серверных компонентах инфраструктура. Так что мой аргумент против JSF - это общий аргумент против серверных платформ, основанных на компонентах.

Основной недостаток серверных сред на основе компонентов заключается в том, что вы не контролируете, что будет выводить компонент, а это означает, что вы застряли с внешним видом компонента, если вы хотите что-то, что выглядит по-другому, вы должны написать свой собственный компонент или у вас изменить существующий компонент. Веб-браузеры в настоящее время развиваются очень быстро, добавляя новые функции, которые действительно могут улучшить качество пользовательского интерфейса приложения, но вам эти функции приходится писать непосредственно на HTML, CSS и JavaScript, а компоненты на стороне сервера усложняют задачу.

Компоненты архитектуры на стороне клиента здесь и намного лучше, чем компоненты на стороне сервера. Вот мой рекомендуемый стек.

Архитектура на стороне клиента:

• jquery.js - базовая библиотека, чтобы все браузеры выглядели одинаково для JavaScript
• backbone.js + underscore.js - высокоуровневая клиентская архитектура на основе компонентов
• handlebars.js - для шаблонов на стороне клиента
• Twitter bootstrap - чтобы получить приличный стартовый набор CSS и виджетов

Вы пишете код на HTML, CSS и JavaScript, организованном в виде базовых представлений, которые взаимодействуют с моделями на стороне сервера с использованием AJAX. Вы имеете полный контроль над пользовательским интерфейсом на стороне клиента с достаточной структурой, чтобы действительно создать хороший повторно используемый код.

Архитектура на стороне сервера:

• Аннотация MVC Spring Services, Услуги и Dao (@Controller, @Service, @Repository)
• Spring компонентное сканирование с автопроводкой по типу (@Autowired, @Inject)
• AspectJ Время загрузки или время компиляции
• зимовать
• Tomcat 7
• JSP как технология представления для Spring MVC (да, это неудобно, но вы не будете создавать слишком много страниц JSP, в основном для директивы usng <% @inculde>

Инструменты: - Spring Tool Suite - JRebel (так что вам не нужно запускать и останавливать сервер), он действительно работает действительно стоит денег - Tomcat 7