что использовать, управляемые бины (поддерживающие бины) или бины сущностей? - PullRequest
Новая
       11

что использовать, управляемые бины (поддерживающие бины) или бины сущностей?

14 голосов
/ 11 декабря 2011

Я вижу много примеров, помечающих bean-компоненты как bean-компоненты Entity Beans (@Entity) и именованные bean-компоненты (CDI), чтобы избежать создания 2 классов (управляемый bean-компонент и entity-Bean), а также использовать проверку Bean для проверки может выполняться как на клиенте, так и на сервере.

Так должен ли я использовать один класс или нет, есть ли какие-либо проблемы или мне нужно, чтобы мои управляемые bean-компоненты или сервисный уровень создавали bean-объекты сущностей, используя данные из управляемых bean-компонентов?

1 Ответ

14 голосов
/ 11 декабря 2011

Аннотации @Named или @ManagedBean обычно используются, чтобы позволить контейнеру компонента (CDI / JSF) создавать экземпляр компонента по требованию при обращении из языка выражений в JSF.

Для компонента @Entityчасто не имеет особого смысла просто получать произвольный новый экземпляр.@Entity очень сильно связан с постоянной идентичностью.Таким образом, такая сущность запрашивается из Entity Manager, а не из контейнера bean-компонента.

Типичным шаблоном является наличие (тонкого) поддерживающего компонента, который называется вызовом службы (который, в свою очередь, обычно@Stateless в Java EE).Служба затем возвращает объекты.

В некоторых очень тривиальных системах люди иногда делают службу именованной и, таким образом, напрямую доступной для EL.Однако, в конце концов, вы часто хотите, чтобы «вспомогательный код» генерировал сообщения лиц или обрабатывал выборки (таблицы), которые не должны быть предметом чисто бизнес-службы.

Другой распространенный способ - позволитькомпонент поддержки напрямую содержит бизнес-код (например, менеджер сущностей, который извлекает сущности).Это делает бизнес-код сложным для повторного использования, но если приложение тривиально и нет необходимости в повторном использовании, вам может это сойти с рук.

Но позволить сущности-be-компоненту-бэку редкои против общих шаблонов Java EE.

Просто обратите внимание, что компонент поддержки может возвращать объект напрямую, так что проверка компонента все еще может использоваться.Нет никакой необходимости в странном паттерне «разбрасывать / собирать», который давно закрался (см. Второй пример в этот вопрос ).

Например, 

@ViewScoped
@ManagedBean
public class BackingBean {

     private SomeEntity myEntity; // + getter

     @EJB  
     private Service service;

     @PostConstruct
     public void init() {
         myEntity = service.getSomeEntity();
     }

     public void save() {
         service.save(myEntity);
         FacesContext.getCurrentInstance().addMessage(..., ...);
     }
 }

Предполагая SomeEntity в аннотированном бине @Entity, проверка бина теперь может использоваться в Facelet, например: 

<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:h="http://java.sun.com/jsf/html"
>    
    <h:body>   
        <h:form>      
            <h:inputText value="#{backingBean.myEntity.name}" />                        
            <h:commandButton value="Save" action="#{backingBean.save}" />
        </h:form>            
    </h:body>
</html>

Если есть ограничение на SomeEntity.name, оно будет проверено.

...