¿Cuál es la mejor práctica en el uso de entidades JPA?JPA POJO como objeto de datos
Dado que las entidades JPA son solo POJO, ¿se considera apropiado utilizar el objeto como objeto de datos en otras partes del sistema o debería convertirlo a otro objeto de datos?
¿Es aceptable utilizar los POJO de la entidad JPA en otras partes del sistema no relacionadas con JPA?
Las entidades ahora son capaces de transportar sus propios datos, entonces, ¿por qué molestarse en convertirlos en algo más? En otras palabras, estoy de acuerdo con DTO an AntiPattern in EJB 3.0:
La naturaleza de peso pesado de beans de entidad en las especificaciones EJB antes de EJB 3.0, dio como resultado el uso de patrones de diseño como Data Transfer Objects (DTO). Los DTO se convirtieron en los objetos livianos (que deberían haber sido los beans de entidad en primer lugar), utilizados para enviar los datos a través de los niveles. [...]
La especificación EJB 3.0 hace que el modelo de bean Entity sea el mismo que el objeto antiguo Java simple (POJO). Con este nuevo modelo POJO, ya no será necesario crear un DTO para cada entidad o para un conjunto de entidades. Si desea enviar las entidades EJB 3.0 a través del nivel, simplemente impleméntelas en
java.io.Serialiazable.
Depende de lo que quiere decir con "otras partes". Dado que sus entidades JPA tienen que estar relacionadas de alguna manera con su sistema, ¿por qué no utilizarlas ya que están allí? El punto importante es que no se usa la misma clase para dos preocupaciones completamente diferentes (que en ese caso es una indicación de mal diseño o solo un sistema realmente grande). Todo lo demás probablemente terminará en un mapeo interminable entre los diferentes problemas de POJO.
Por ejemplo, un usuario de inicio de sesión. Podría ser una práctica verbosa común en Java crear un UserLoginForm Bean separado para un inicio de sesión basado en web, pero considere esto:
Ya tiene sus entidades JPA de usuario (y por lo tanto un usuario POJO) en la base de datos (tiene un nombre de usuario, contraseña hash, dirección y probablemente otras cosas almacenadas). También puede usar exactamente el mismo objeto en su solicitud de inicio de sesión desde el formulario web (algunos Frameworks como Spring lo mapearán de inmediato). Cree un objeto Usuario vacío, establezca el nombre de usuario y la contraseña hash y haga una consulta JPA por ejemplo. Si esa consulta devuelve exactamente un resultado, el inicio de sesión es válido y puede almacenar el objeto de usuario cargado en la sesión.
Esta es una buena pregunta.
Al exponer las clases de entidad JPA al resto del sistema, expone el mecanismo de persistencia y el objeto al mapeo db. Pierde control sobre cómo se CRUDDAN y administran estos objetos. Al romper la encapsulación de persistencia, un cambio puede tener un efecto dominó en el resto del sistema.
Los cambios futuros a la persistencia del sistema pueden ser imposibles, extravagantes, limitados y/o riesgosos. Ejemplo: es posible que necesite optimizar el rendimiento y/o la escalabilidad. Esto puede requerir el almacenamiento en caché, cambios en el esquema db, uso no RDBMS, múltiples bases de datos. La encapsulación también ayuda a mitigar la migración a futuros esquemas db.
Así que la compensación es:
La primera opción puede ser necesaria si los cambios frecuentes de todo el sistema no son aceptables, p. Los terceros están accediendo a sus datos. O tal vez se haya decidido por una arquitectura de 3 capas: GUI, lógica de negocios, persistencia.
La segunda opción es correcta si tiene un proceso de desarrollo ágil y tiene control sobre todo el sistema y acepta el hecho de que puede ser necesario un cambio en todo el sistema más adelante.
Acreditandote con respuesta porque has vinculado a documentación interesante sobre antipatrón. – Tazzy531