Связь между EJB 3.0 и JPA?

Это может показаться очевидным, но я видел противоречивые заявления: Является ли JPA частью EJB 3.0? Я не специалист, и это довольно запутанно для меня.

Если это так, JPA манипулирует Entity Beans? Эта сущность beans является интерфейсом между уровнем персистентности и бизнес-уровнем, реализующим логику с помощью безстоящего Beans?

Основной вопрос для меня заключается в том, как реализовать функцию "поиск пользователя на основе различных критериев", где должен быть создан запрос "поиск" - представление строки? Я имею в виду, если JPA не является частью EJB, мой beans не должен знать модель данных, верно?

Где граница?

Ответ 1

Является ли JPA частью EJB 3.0?

Да и нет... Да, потому что каждый сервер приложений, требующий внедрения спецификации EJB 3.0, должен также обеспечивать реализацию JPA. Нет, поскольку JPA может быть легко вне EJB, в автономных приложениях или Spring -управленных.

JPA манипулирует Entity Beans?

Сущность Beans была страшной идеей в пред-3.0 EJB. JPA использует термин "сущности", чтобы отличить себя от позорной истории. Но да, объекты JPA - это способ сопоставления таблиц базы данных с обычными объектами Java. В принципе, изменения, внесенные в объект, распространяются в базу данных и наоборот (упрощение).

Как я уже сказал, JPA не имеет никакой зависимости от EJB (рассматривается как сеанс без состояния и состояния beans), а наоборот. Но нет ничего препятствующего использованию JPA в EJB.

В вашем сценарии у вас будет безгосударственный EJB, создающий запрос и взаимодействующий с базой данных через JPA. С технической точки зрения вы вызовете методы на EntityManager, введенные в ваш bean:

@Stateless
public class SearchService {

    @PersistenceContext
    private EntityManager em;

    public List<User> findUsersBornAfter(Date date) {
        return em.
            createQuery("SELECT u FROM User u WHERE u.birthDate > :birthDate ORDER BY name").
            setParameter("birthDate", date).
            getResultList();
    }
}

Как вы можете видеть, бизнес-уровень знает модель данных (очевидно), но не существует зависимости от EJB/бизнес-сервисов в отношении объектов. В этом примере на уровне обслуживания формируется JPQL (запрос), а User - объект JPA. Вызов getResultList() заставляет провайдера JPA переводить JPQL на SQL, запускать запрос и трансалировать результаты обратно в экземпляры объектов User.

Является ли теперь граница между EJB и JPA прозрачной?

Ответ 2

Несколько примечаний:

когда речь заходит о JSR, JPA 1.0 была частью EJB 3.0. См. здесь, JPA 2.0 - отдельный JSR (см. здесь)
"entity beans" - EJB pre-3.0, и они, к счастью, мертвы. Их преуспевает JPA.
когда дело доходит до зависимостей - JPA не зависит от EJB, а EJB не зависит от JPA. Однако EJB может обрабатывать инъекцию менеджера сущностей JPA
вы можете использовать любой из них автономный
каждый сервер приложений поддерживает как

Ответ 3

Добавление в ответ BalusC, из Википедии - Enterprise JavaBean:

Обратите внимание, что текущая спецификация EJB 3.1 не описывает, как сервер приложений обеспечивает постоянство (задача, делегированная спецификации JPA), но вместо этого подробно описывает, как бизнес-логика может легко интегрироваться с услугами сохранения, предлагаемыми сервером приложений.

Интеграция убирает некоторые точки боли из JPA, а именно довольно многословный и шумный запуск и совершение/откатывание транзакции и определение области extended persistence context (последняя последняя только для statefull session beans).

Добавление к ответу Божо:

В EJB 3.0 JPA 1.0 был частью EJB, но в качестве вспомогательной спецификации и используемого внешнего EJB и вне Java EE.
В EJB 3.1 JPA полностью отделилась от EJB, а JPA 2.0 - на 100% отдельно JSR.

Ответ 4

Из Википедии - API Java Persistence:

Enterprise JavaBeans

Спецификация EJB 3.0 (сама часть платформы Java EE 5) включала определение Java Persistence API. Тем не менее конечным пользователям не нужен контейнер EJB или сервер приложений Java EE для запуска приложений, которые используют этот API персистентности. [1] Будущие версии API Java Persistence будут определены в отдельной спецификации JSR и спецификации, а не в спецификации EJB JSR/. API-интерфейс Java Persistence заменяет решение по сохранению EJB 2.0 CMP (Container Managed Persistence).