example - Relación entre EJB 3.0 y JPA?

persistence.xml netbeans

Question

Esto puede parecer obvio, pero he visto afirmaciones contradictorias: ¿JPA forma parte de EJB 3.0? No soy especialista y es bastante confuso para mí.

Si es así, ¿JPA manipula a los beans de entidad? ¿Estos beans de entidad son la interfaz entre la capa de persistencia y la capa de negocios que implementa la lógica con los beans sin estado?

La pregunta subyacente para mí es cómo implementar una función de "búsqueda de usuario basada en varios criterios", donde se debe construir la solicitud de "búsqueda" (su representación de cadena). Quiero decir, si JPA no es parte de EJB, mis beans no deberían conocer el modelo de datos, ¿verdad?

¿Dónde está el límite?

Answer 1

¿Es JPA parte de EJB 3.0?

Sí y no ... Sí, porque todos los servidores de aplicaciones que afirman implementar la especificación EJB 3.0 también deben proporcionar la implementación JPA. No, porque JPA puede estar fácilmente fuera de EJB, en aplicaciones independientes o administradas por Spring.

¿JPA manipula a los beans de entidad?

Los beans de entidad fueron una idea aterradora en los EJB anteriores a 3.0. JPA usa el término entidades para distinguirse de la historia vergonzosa. Pero sí, las entidades JPA son una forma de asignar tablas de base de datos a objetos Java simples. En principio, los cambios realizados en el objeto se propagan a la base de datos y viceversa (simplificación excesiva).

Como dije, JPA no tiene ninguna dependencia de EJB (considerados como beans de sesión sin estado y con estado) y al revés. Pero no hay nada que le impida utilizar JPA en EJB.

En su escenario, tendrá un EJB sin estado que construye la consulta e interactúa con la base de datos a través de JPA. Técnicamente hablando, llamará a los métodos en EntityManager inyectados a su 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();
    }
}

Como puede ver, la capa empresarial es consciente del modelo de datos (obviamente), pero no hay dependencia en los servicios de EJB / negocios en lo que respecta a las entidades. En este ejemplo, JPQL (consulta) se forma en la capa de servicio y el User es una entidad JPA. Al llamar a getResultList() , el proveedor de JPA traduce JPQL a SQL, ejecuta la consulta y traduce los resultados a las instancias de objeto de User .

¿Está libre ahora la frontera entre EJB y JPA?

Answer 2

Agregando a la respuesta de BalusC, de Wikipedia - Enterprise JavaBean:

Tenga en cuenta que la especificación EJB 3.1 actual no detalla cómo un servidor de aplicaciones proporciona persistencia (una tarea delegada a la especificación JPA), sino que detalla cómo la lógica de negocios puede integrarse fácilmente con los servicios de persistencia ofrecidos por el servidor de aplicaciones.

La integración quita algunos puntos débiles de JPA, es decir, el inicio y el cometer / deshacer de forma bastante detallada y ruidosa de una transacción y el alcance del extended persistence context (que dura solo para los beans de sesión de estado completo).

Añadiendo a la respuesta de Bozho:

• En EJB 3.0, JPA 1.0 era parte de EJB pero como subespecificación y utilizable fuera de EJB y fuera de Java EE.
• En EJB 3.1, JPA se ha separado completamente de EJB y JPA 2.0 es 100% un JSR separado.

Answer 3

De Wikipedia - Java Persistence API:

Enterprise JavaBeans

La especificación EJB 3.0 (en sí misma parte de la plataforma Java EE 5) incluía una definición de la API de persistencia de Java. Sin embargo, los usuarios finales no necesitan un contenedor EJB o un servidor de aplicaciones Java EE para ejecutar aplicaciones que utilizan esta API de persistencia. [1] Las versiones futuras de la API de persistencia de Java se definirán en una JSR y especificación por separado en lugar de en la especificación / JSR de EJB. La API de persistencia de Java reemplaza la solución de persistencia de EJB 2.0 CMP (persistencia administrada por contenedor).

Answer 4

Un par de notas:

• cuando se trata de JSR, JPA 1.0 era parte de EJB 3.0. Ver aquí , JPA 2.0 es un JSR separado ( ver aquí )
• "beans de entidad" son EJB pre-3.0, y por suerte están muertos. Son sucedidos por JPA.
• cuando se trata de dependencias - JPA no depende de EJB, y EJB no depende de JPA. Sin embargo, EJB puede manejar la inyección del administrador de entidades JPA
• Usted puede utilizar cualquiera de ellos independiente
• cada servidor de aplicaciones soporta ambos