CDI bean-производитель внутри EJB-сессии без состояния

Question

Предположим, у меня есть простая библиотека с именем db-utils, в которой используется CRI-компонент CrudService (requestScoped), который используется моими веб-приложениями для выполнения операций CRUD.

У меня также есть проект EJB с именем grad-db, который имеет сущности, отображенные из базы данных. Grad-db также имеет производителя, используемого для установки entityManager в crdService db-utils.

Я уже пробовал и, видимо, отлично работает. Мой вопрос: это плохая практика? Есть ли какое-либо следствие создания бина CDI внутри сессионного bean-компонента без состояния и передачи компонента без учета состояния EJB в качестве параметра для CrudService?

Мой код:

EJB Bean (град-дб):

@Stateless 
public class CrudServiceCae extends AbstractCrud implements Serializable { 
    private static final long serialVersionUID = 1L; 

    @PersistenceContext(unitName = "cae-pu") 
    EntityManager em; 

    @Override 
    public EntityManager getEntityManager() { 
     return em; 
    } 

    @Produces 
    @Database(Schema.CAE) 
    public CrudService createCrudServiceCou() { 
     return new CrudService(this); 
    } 
} 

CrudService (DB-Utils):

@Named("crudService") 
public class CrudService implements Serializable { 

    private static final long serialVersionUID = -2607003150201349553L; 

    private AbstractCrud crud; 

    public CrudService(AbstractCrud abstractCrud) { 
     this.crud = abstractCrud; 
    } 

    ... 
} 

Edit: На самом деле он работал только для запросы. Когда я попытался вставить данные, я получил javax.persistence.TransactionRequiredException. По-видимому, в этом случае мне придется использовать наследование вместо CDI.

Answer 1

EJB отвечают за бизнес-процессы/логику (то есть методы) и могут управлять другими контроллерами CDI, не так распространены, что EJB создает объекты, для чего вы предпочтете CDJ POJO Producer.

В вашем случае более компактный, чтобы использовать объект CDI и производить объект, который вам нужен, выглядит как DAO и может использоваться (я имею в виду, впрыскивается) в EJB.

Подумайте о EJB на условиях Граница, используя специализированные контроллеры.

Примечания:

• @Stateless не требуется реализует Serializable, они объединяются, и его жизненный цикл не позволяет сериализации.
• В общем, вы не хотите использовать getter для диспетчера сущностей EJB, вы должны предпочесть написать метод и внутренне использовать em.
• Контекст живучесть легче манипулировать, если используется JTA
• Ваш @Stateless должен начинает операции, и пусть они распространяются по контроллерам
• em с видимостью пакета является хорошей идеей, позволяет вам издеваться свой фасад/границу легко