¿Cómo funciona ORM debajo de las sábanas? Además, ¿cuál es la mejor manera de tener objetos persistentes en Java?
https://stackoverflow.com/questions/1231295
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
¿Cómo funciona ORM? ¿Los objetos se serializan en BLOB?
En Java, ¿JDO sigue siendo el camino a seguir para esto? ¿Qué más hay disponible? Parece que se habló mucho de EJB, serialización directa de objetos y JDO.
Solución
Para responder a su primera pregunta, aquí hay un extracto de Hibernate in Action , eso dice que hay varias formas de implementar ORM:
Relacional puro
Toda la aplicación, incluida la interfaz de usuario, está diseñada alrededor del modelo relacional y basado en SQL operaciones relacionales. Este enfoque, a pesar de sus deficiencias para grandes sistemas, pueden ser una excelente solución para aplicaciones simples donde un bajo El nivel de reutilización del código es tolerable. SQL directo se puede ajustar en cada aspecto, pero los inconvenientes, como falta de portabilidad y mantenibilidad, son importantes, especialmente a largo plazo. Aplicaciones en esta categoría a menudo hacer un uso intensivo de los procedimientos almacenados, desplazando parte del trabajo fuera del capa empresarial y en la base de datos.
Mapeo de objetos ligeros
Las entidades se representan como clases que se asignan manualmente a la Tablas relacionales. SQL / JDBC codificado a mano está oculto de la lógica de negocios utilizando patrones de diseño bien conocidos. Este enfoque está extremadamente extendido y es exitoso para aplicaciones con un pequeño número de entidades, o aplicaciones con genérico, modelos de datos basados ??en metadatos. Almacenado procedimientos podrían tener un lugar en este tipo de aplicación
Asignación de objeto medio
La aplicación está diseñada en torno a un modelo de objeto SQL se genera en construir tiempo usando una generación de código herramienta, o en tiempo de ejecución por código marco. Las asociaciones entre objetos son apoyado por la persistencia mecanismo, y las consultas pueden ser especificado utilizando un objeto orientado lenguaje de expresión Los objetos son almacenado en caché por la capa de persistencia. UNA gran cantidad de productos ORM y de cosecha propia las capas de persistencia soportan al menos Este nivel de funcionalidad. Esta bien adecuado para aplicaciones medianas con algunas transacciones complejas, particularmente cuando la portabilidad entre diferentes productos de base de datos es importante. Estas aplicaciones usualmente no use procedimientos almacenados.
Asignación completa de objetos
Soporte completo de mapeo de objetos modelado sofisticado de objetos: composición, herencia, polimorfismo y "persistencia por accesibilidad ". La capa de persistencia implementa persistencia transparente; las clases persistentes no heredan ninguna clase base especial o tiene que Implementar una interfaz especial. Estrategias de búsqueda eficientes (perezoso y ansioso por buscar) y el almacenamiento en caché se implementan estrategias transparente a la aplicación. Esta nivel de funcionalidad difícilmente puede ser logrado por una persistencia de cosecha propia capa: es equivalente a meses o años de tiempo de desarrollo. Un número de Java ORM comercial y de código abierto las herramientas han alcanzado este nivel de calidad. Este nivel cumple con el definición de ORM que estamos usando en este libro. Veamos los problemas que tenemos esperar ser resuelto por una herramienta que logra el mapeo completo de objetos.
Otros consejos
ORM = Asignación relacional de objetos, los atributos de los objetos se asignan a columnas en la base de datos relacional. Ese mapeo es arbitrario, por lo que podría hacerse a blobs, en la práctica, lo que es más útil tiende a los mapeos naturales: cadenas a varchars, int a enteros, etc.
JPA es el lugar para buscar un estándar para ORM. JPA reemplaza el enfoque EJB CMP, que resultó ser engorroso. JPA le permite expresar la asignación como anotaciones de Java y también permite que las asignaciones se especifiquen en archivos de configuración, cuando admite múltiples bases de datos, esta última puede ser útil.
JPA tiene un lenguaje de consulta para que pueda construir consultas con atributos de objeto.
JPA es compatible con los principales proveedores de servidores de aplicaciones y también con productos como Hibernate.
Me pareció muy agradable trabajar con JPA, más que con EJB CMP.
Recomendaría seguir usando fachadas de beans de sesión EJB para la gestión y seguridad de las transacciones: el enfoque basado en anotaciones hace que EJB 3 way sea más fácil de usar que EJB 2, mínima sobrecarga de codificación.
JDO también es ORM estándar y proporciona una especificación más completa que JPA (1 + 2). JPQL está más centrado en los conceptos RDBMS y, por lo tanto, imita SQL. JDOQL sigue la sintaxis de Java, por lo que se basa más en objetos. Depende de si alguna vez se considera que su aplicación se aleja de RDBMS. Si es así, entonces JPA no es el camino a seguir. Si es únicamente para RDBMS, entonces JPA es definitivamente una consideración.
Si los objetos se serializan en BLOB depende de su configuración. Puede hacerlo para los tipos de objetos complejos si lo desea, pero luego no serán consultables. Si, en cambio, los conserva en forma nativa, también puede consultarlos, lo que lleva a aplicaciones más eficientes.
--Andy (DataNucleus - JDO y JPA persistencia)
