Архитектура JSF-SPRING-HIBERNATE — лучшая практика поддержки bean-компонентов

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

Актер --> страница JSF+PrimeFaces --- > Backing Bean -- > Service Bean -- > Dao -- > Hibernate

  • Service Bean и DAO — это spring bean-компоненты с внедрением зависимостей.

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

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

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

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

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


spring hibernate orm javabeans backing
person Bipin    schedule 14.05.2012    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Общее правило, которому я следую, заключается в том, что границы транзакций отмечены в сервисных компонентах, поэтому мне не нравится модифицировать hibernate 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 — чтобы получить достойный стартовый набор CSS и виджетов

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

Серверная архитектура:

  • Spring MVC, службы и дао, управляемые аннотациями (@Controller, @Service, @Repository)
  • Сканирование компонентов Spring с автопроводкой по типу (@Autowired, @Inject)
  • Переплетение времени загрузки AspectJ или переплетение времени компиляции
  • Спящий режим
  • Томкэт 7
  • JSP как технология просмотра для Spring MVC (да, это неуклюже, но вы не будете создавать слишком много страниц jsp, в основном для директивы usng ‹% @inculde >

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

person ams    schedule 24.06.2012