Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Introducción a ORMs

968 visualizaciones

Publicado el

Introducción al mapeo Objeto/Relacional.

Publicado en: Tecnología
  • Sé el primero en comentar

Introducción a ORMs

  1. 1. ORM: Object-Relational Mapping Grupo Azulejos
  2. 2. ¿Qué es un ORM? En el desarrollo de una aplicación suelen estar involucradas dos entidades diferentes, por una parte el código que mueve la aplicación y por otra los datos que se manejan (División en capas). Los sistemas de Mapeo Objeto-Relacional u ORM ayudan a hacer la transición de lenguaje orientado a objetos a la base de datos que se utilice.
  3. 3. ¿Qué es un ORM? Permite ver y modificar los datos almacenados en una base de datos relacional usando el lenguaje de programación elegido y organiza las tablas o procedimientos almacenados en clases, por lo que en vez de utilizar consultas SQL para comunicarse con la base de datos se usan métodos y propiedades de objetos.
  4. 4. ¿Qué es un ORM? La característica más importante de ORM es el mapeo. El mismo se usa para persistir objetos almacenados en una base de datos. Un objeto y sus propiedades están típicamente relacionados a una o más tablas y sus campos en la base de datos. El ORM usa la información de esta relación para gestionar el proceso de conversión de tablas a objetos y viceversa generando las consultas SQL necesarias para que la base de datos relacional gestione el CRUD de los objetos de dominio de la aplicación.
  5. 5. Ventajas en el uso de ORMs.
  6. 6. Algunos beneficios de usar un ORM. ● Se encarga de gestionar la conversión de tipos DATE y TIME en forma automática. ● Se encarga de hacer el trabajo “pesado” de asociar los valores de los campos de cada registro de una tabla en los respectivos atributos del objeto. ● Al brindar seguridad en diversos aspectos, previene ataques de inyección SQL. ● Para consultas complejas, muchos ORM brindan extensiones para escribir consultas en SQL nativo.
  7. 7. Algunos beneficios de usar un ORM. ● Generación de código (Entities and Schemas). ● Puede mejorar con creces la velocidad de desarrollo, sobre todo cuando el esquema de la base de datos todavía no se encuentra maduro. Es muy tedioso reescribir una consulta SQL cada vez que se introduce una modificación en dicho esquema, lo cual conlleva a una pérdida de tiempo de producción. ● El uso de caché puede implicar velocidades de acceso a datos mucho mayores.
  8. 8. Desventajas en el uso de ORMs.
  9. 9. Algunas desventajas de usar un ORM. ● Se puede llegar a perder la noción acerca de cuánto tiempo se invierte retocando archivos XML o anotaciones, con el objetivo de optimizar la performance del ORM. ● Un mal uso de los sistemas ORMs (debido al desconocimiento del funcionamiento interno) puede reducir la performance de la aplicación en forma drástica. Todo depende del programador y la optimización en el uso del mismo.
  10. 10. Algunas desventajas de usar un ORM. ● De por sí al agregar una capa más que se encarga abstraer al programador del acceso a los datos agregamos mayor complejidad con lo cual la latencia puede ser mayor.
  11. 11. Cuándo SI utilizar ORMs.
  12. 12. ¿Cuándo utilizar un ORM? ● Para aplicaciones transaccionales (CRUD), en las que se realiza una petición, se buscan un conjunto de objetos en la BD, se los procesa y se renderiza una página web. La performance utilizando un ORM pueden ser mucho mejor si dichos objetos se encuentran en la caché del ORM.
  13. 13. Cuándo NO utilizar ORMs.
  14. 14. ¿Cuándo NO utilizar un ORM? ● Para aplicaciones que requieren la generación de reportes en los cuales intervienen un gran número de registros por cada petición, el trabajo que lleva a cabo el ORM no es eficiente debido a que puede saturar la memoria de objetos.
  15. 15. ¿Cuándo NO utilizar un ORM? ● Los ORMs pueden ser optimizados para ser lo más eficientes posibles, y esto muchas veces es suficiente. Sin embargo en entornos donde se manejan un gran volumen de datos y que requieren de una baja latencia, los ORMs son un no rotundo.
  16. 16. Opiniones a partir de las experiencias de diversos profesionales.
  17. 17. Opiniones de Profesionales ● “En aplicaciones a gran escala, te encontrarás usando ambos enfoques. ORM para llevar a cabo el CRUD y una capa de acceso a datos fina de SQL para reportes.” ● “Para consultas complejas, realmente no hay sustitutos para plain SQL. Existen algunas consultas en JPA que no son posibles de llevar a cabo...”
  18. 18. Opiniones de Profesionales ● “ORM no se trata sólo de portabilidad. Básicamente te provee de una capa de abstracción de acceso a datos. Un ORM libera al programador de escribir consultas SQL y concentrar su atención en el dominio del problema.” ● “Yo diría que SQL plano para reads (R), y ORM para creates, updates y deletes (CUD).”
  19. 19. Opiniones de Profesionales ● “En mi experiencia como desarrollador, he encontrado que los ORM son útiles cuando hay que gestionar transacciones (operaciones insert/update/delete), pero cuando se trata de recolectar datos con resultados complejos, resulta muy importante evaluar la performance y la eficiencia de una herramienta ORM.”
  20. 20. Opiniones de Profesionales ● “Si al usar un ORM no se obtiene ninguna ventaja real, y la aplicación es muy sencilla, yo no usaría un ORM. Un ejemplo claro es si la aplicación en cuestión se trata acerca de procesar grandes conjuntos de registros y no hay mucha lógica de negocio. Eso no significa que tu aplicación no fuera diseñada de la manera apropiada, pero, una vez más: Si usar un ORM no te brinda ningún beneficio, entonces.. ¿Porque lo usarías?”
  21. 21. Opiniones de Profesionales ● “Muchas veces es preferible un código que sea fácil de mantener, sacrificando performance. En lo personal creo que un código fácil de mantener es más económico, ya que si la aplicación es escalable, el costo del hardware asociado es menor al de horas/hombre.”
  22. 22. ORM más conocidos: Características y comparaciones. Ejemplos.
  23. 23. Ejemplos La mayoría de los ORM se fundan sobre las mismas bases e inclusive suelen trabajar de forma muy similar. Algunos ejemplos de ORMs son: ● Hibernate (Java) ● Entity Framework (.NET) ● Doctrine (PHP) ● SQLAlchemy (Python) ● Active Record (Ruby)
  24. 24. Algunas Características ● Hibernate (Java) y SQLAlchemy (Python) se basan en el patrón estructural DATA MAPPER. ● Doctrine (PHP) y Active Record (Ruby) se basan en el patrón estructural ActiveRecord.
  25. 25. Algunas Características ● Todos ellos brindan soporte para: o Anotaciones/ XML para la definición del mapeo. o Transacciones. o Soporte para herencias y asociaciones entre clases. o Sus propios lenguajes de consulta (DQL, HQL, etc). o Caché (Doctrine PHP -> APC, Memcached, Xcache) o Consultas personalizadas (Doctrine QueryBuilder)
  26. 26. Hibernate Hibernate es una herramienta de Mapeo objeto relacional (ORM) para la plataforma Java (y disponible también para .Net con el nombre de NHibernate) que facilita el mapeo de atributos entre una base de datos relacional tradicional y el modelo de objetos de una aplicación, mediante archivos declarativos (XML) o anotaciones en los beans de las entidades que permiten establecer estas relaciones. Hibernate ofrece también un lenguaje de consulta de datos llamado HQL (Hibernate Query Language), al mismo tiempo que una API para construir las consultas programáticamente (conocida como "criteria").
  27. 27. ADO.NET - Entity Framework Una entidad del Entity Framework es un objeto que tiene una clave representando la clave primaria de una entidad lógica de datastore. Un modelo conceptual Entity Data Model (modelo Entidad Relación) es mapeado a un modelo de esquema de datastore. Usando el Entity Data Model, el Framework permite que los datos sean tratados como entidades independientemente de sus representaciones del datastore subyacente.
  28. 28. ADO.NET - Entity Framework El Entity SQL es un lenguaje similar al SQL para consultar el Entity Data Model (en vez del datastore subyacente). Similarmente, las extensiones del Linq, LinqtoEntities, proporcionan consultas tipeadas en el Entity Data Model. Las consultas Entity SQL y Linqto- Entities son convertidas internamente en un Canonical Query Tree que entonces es convertido en una consulta comprensible al datastore subyacente (ej. en SQL en el caso de una base de datos relacional). Las entidades pueden utilizar sus relaciones, y sus cambios enviados de regreso al datastore.
  29. 29. Doctrine (PHP) Doctrine es un mapeador de objetos relacional (ORM) escrito en PHP que proporciona una capa de persistencia para objetos PHP. Es una capa de abstracción que se sitúa justo encima de un SGBD. Una característica de Doctrine es el bajo nivel de configuración que necesita para empezar un proyecto. Doctrine puede generar clases a partir de una base de datos existente y después el programador puede especificar relaciones y añadir funcionalidad extra a las clases autogeneradas.
  30. 30. Doctrine (PHP) No es necesario generar o mantener complejos esquemas XML de base de datos como en otros frameworks. Otra característica importante de Doctrine es la posibilidad de escribir consultas de base de datos utilizando un dialecto de SQL denominado DQL (Doctrine Query Language) que está inspirado en Hibernate (Java).

×