ventajas mejor mapeo framework ejemplos desventajas orm

mejor - orm mapeo



¿Cuáles son las ventajas de usar un ORM? (13)

Como desarrollador web que busca pasar de sitios PHP codificados a mano a sitios basados ​​en marcos, he visto mucha discusión sobre las ventajas de un ORM sobre otro. Parece ser útil para proyectos de cierto tamaño (?) , Y aún más importante para aplicaciones de nivel empresarial.

¿Qué me da como desarrollador? ¿En qué se diferencia mi código de las declaraciones SELECT individuales que uso ahora? ¿Cómo ayudará con el acceso a la base de datos y la seguridad? ¿Cómo se entera sobre el esquema DB y las credenciales del usuario?

Editar: @duffymo señaló lo que debería haber sido obvio para mí: ORM solo es útil para código OOP. Mi código no es OO, así que no me he encontrado con los problemas resueltos por ORM.

¿Qué me da como desarrollador?

Le ahorra tiempo, ya que no tiene que codificar la parte de acceso db.

¿En qué se diferencia mi código de las declaraciones SELECT individuales que uso ahora?

Utilizará atributos o archivos xml para definir la asignación de clase a las tablas de la base de datos.

¿Cómo ayudará con el acceso a la base de datos y la seguridad?

La mayoría de los marcos intentan adherirse a las mejores prácticas de db donde corresponda, como el SQL parametrizado y demás. Como el detalle de la implementación está codificado en el marco, no tiene que preocuparse por ello. Por esta razón, sin embargo, también es importante comprender el marco que está utilizando, y tener en cuenta los defectos de diseño o errores que pueden abrir agujeros inesperados.

¿Cómo se entera sobre el esquema DB y las credenciales del usuario?

Usted proporciona la cadena de conexión como siempre. Los proveedores del framework (p. Ej. SQL, Oracle, clases específicas de MySQL) proporcionan la implementación que consulta el esquema db, procesa las asignaciones de clase y representa / ejecuta el código de acceso db según sea necesario.

Beneficios principales:

  1. Abstracción de base de datos
  2. Mentalidad de diseño centrado en API
  3. Nivel alto == Menos de qué preocuparse en el nivel fundamental (ha sido pensado por ti)

Debo decir que trabajar con un ORM es realmente la evolución de las aplicaciones basadas en bases de datos. Se preocupa menos por el SQL repetitivo que siempre escribe, y más acerca de cómo las interfaces pueden trabajar juntas para hacer un sistema muy sencillo.

Me encanta no tener que preocuparme por INNER JOIN y SELECT COUNT (*). Solo trabajo en mi abstracción de alto nivel, y me he ocupado de la abstracción de la base de datos al mismo tiempo.

Habiendo dicho eso, nunca me he encontrado con un problema donde necesite ejecutar el mismo código en más de un sistema de base de datos a la vez de manera realista. Sin embargo, eso no quiere decir que el caso no exista, es un problema muy real para algunos desarrolladores.

El uso de un ORM eliminará las dependencias de su código en un dialecto de SQL particular. En lugar de interactuar directamente con la base de datos, interactuará con una capa de abstracción que proporciona aislamiento entre su código y la implementación de la base de datos. Además, los ORM generalmente brindan protección contra la inyección de SQL al construir consultas parametrizadas. De acuerdo, podría hacerlo usted mismo, pero es bueno tener la garantía del marco.

Los ORM funcionan de dos maneras: algunos descubren el esquema de una base de datos existente (el diseñador de LINQToSQL hace esto), otros requieren que asigne su clase a una tabla. En ambos casos, una vez que se ha mapeado el esquema, el ORM puede crear (recrear) la estructura de su base de datos por usted. Es probable que los permisos DB aún se tengan que aplicar manualmente o mediante SQL personalizado.

Por lo general, las credenciales se suministran programáticamente a través de la API o utilizando un archivo de configuración, o ambos, predeterminados que provienen de un archivo de configuración, pero que se pueden sobrescribir en el código.

En un nivel muy alto: los ORM ayudan a reducir la falta de coincidencia de impedancia relacional entre objetos. Permiten almacenar y recuperar objetos completos en vivo desde una base de datos relacional sin tener que realizar una gran cantidad de análisis / serialización.

¿Qué me da como desarrollador?

Para empezar, te ayuda a mantenerte seco. O bien el esquema o las clases de modelo son autoritativas y el otro se genera automáticamente, lo que reduce la cantidad de errores y la cantidad de código de la placa de la caldera.

Ayuda con la clasificación. Los ORM generalmente manejan la clasificación de los valores de las columnas individuales en los tipos apropiados para que usted no tenga que analizarlos / serializarlos usted mismo. Además, le permite recuperar objetos completamente formados de la base de datos en lugar de simplemente remar objetos para envolver su auto.

¿En qué se diferencia mi código de las declaraciones SELECT individuales que uso ahora?

Como sus consultas devolverán objetos en lugar de solo filas, podrá acceder a objetos relacionados mediante el acceso a atributos en lugar de crear una nueva consulta. En general, puede escribir SQL directamente cuando lo necesite, pero para la mayoría de las operaciones (CRUD), el ORM simplificará el código para interactuar con objetos persistentes.

¿Cómo ayudará con el acceso a la base de datos y la seguridad?

En términos generales, los ORM tienen su propia API para crear consultas (por ejemplo, acceso a atributos) y, por lo tanto, son menos vulnerables a los ataques de inyección SQL; sin embargo, a menudo le permiten insertar su propio SQL en las consultas generadas para que pueda hacer cosas extrañas si es necesario. Tal SQL inyectado usted es responsable de desinfectarse usted mismo, pero, si se mantiene alejado de usar tales características, entonces el ORM debería ocuparse de desinfectar los datos del usuario automáticamente.

¿Cómo se entera sobre el esquema DB y las credenciales del usuario?

Muchos ORM vienen con herramientas que inspeccionarán un esquema y crearán un conjunto de clases modelo que le permitirán interactuar con los objetos en la base de datos. Las credenciales de usuario de [Base de datos] generalmente se almacenan en un archivo de configuración.

La mayoría de las bases de datos utilizadas son bases de datos relacionales que no se traducen directamente en objetos. Lo que hace un asignador relacional de objetos es tomar los datos, crear un caparazón a su alrededor con funciones de utilidad para actualizar, eliminar, insertar y otras operaciones que se pueden realizar. Entonces, en lugar de pensar en ello como un conjunto de filas, ahora tiene una lista de objetos que puede manipular como lo haría con cualquier otro y simplemente llame a obj.Save () cuando haya terminado.

Sugiero que echen un vistazo a algunos de los ORM que están en uso, uno de mis favoritos es el ORM utilizado en el framework Python, django . La idea es que usted escriba una definición de cómo se ve su información en la base de datos y el ORM se encarga de la validación, los controles y cualquier mecanismo que deba ejecutarse antes de insertar los datos.

Los ORM están siendo promocionados por ser la solución a los problemas de acceso a los datos. Personalmente, después de haberlos utilizado en un proyecto empresarial, están lejos de ser la solución para el desarrollo de aplicaciones empresariales. Quizás trabajan en pequeños proyectos. Estos son los problemas que hemos experimentado con ellos específicamente nHibernate:

  1. Configuración: las tecnologías ORM requieren archivos de configuración para mapear esquemas de tablas en estructuras de objetos. En los sistemas de grandes empresas, la configuración crece muy rápidamente y se vuelve extremadamente difícil de crear y gestionar. El mantenimiento de la configuración también se vuelve tedioso y no se puede mantener, ya que los requisitos y modelos empresariales cambian y evolucionan constantemente en un entorno ágil.

  2. Consultas personalizadas: la capacidad de asignar consultas personalizadas que no encajan en ningún objeto definido no es compatible o no es recomendada por los proveedores del framework. Los desarrolladores se ven obligados a buscar soluciones alternativas escribiendo objetos ad hoc y consultas, o escribiendo código personalizado para obtener los datos que necesitan. Es posible que tengan que usar Procedimientos almacenados de manera regular para cualquier cosa más compleja que un simple Seleccionar.

  3. Enlace propietario: estos marcos requieren el uso de bibliotecas propietarias y lenguajes de consulta de objetos patentados que no están estandarizados en la industria de la informática. Estas bibliotecas propietarias y los lenguajes de consulta vinculan la aplicación a la implementación específica del proveedor con poca o ninguna flexibilidad para cambiar si es necesario y sin interoperabilidad para colaborar entre sí.

  4. Idiomas de consulta de objetos: se proporcionan nuevos lenguajes de consulta llamados Lenguajes de consulta de objetos para realizar consultas en el modelo de objetos. Generan automáticamente consultas SQL contra el databse y el usuario se abstrae del proceso. Para los desarrolladores orientados a objetos esto puede parecer un beneficio ya que sienten que el problema de escribir SQL está resuelto. El problema en la práctica es que estos lenguajes de consulta no pueden admitir algunas de las construcciones de SQL intermedio a avanzado requeridas por la mayoría de las aplicaciones del mundo real. También evitan que los desarrolladores modifiquen las consultas SQL si es necesario.

  5. Rendimiento: las capas ORM utilizan reflexión e introspección para instanciar y poblar los objetos con datos de la base de datos. Estas son operaciones costosas en términos de procesamiento y se suman a la degradación del rendimiento de las operaciones de mapeo. Las consultas de objeto que se traducen para producir consultas no optimizadas sin la opción de ajustarlas, causando pérdidas significativas de rendimiento y sobrecarga de los sistemas de administración de bases de datos. El ajuste del rendimiento del SQL es casi imposible ya que los marcos proporcionan poca flexibilidad sobre el control del SQL que se autogenera.

  6. Acoplamiento cerrado: este enfoque crea una estrecha dependencia entre los objetos del modelo y los esquemas de la base de datos. Los desarrolladores no desean una correlación uno a uno entre los campos de la base de datos y los campos de clase. Cambiar el esquema de la base de datos tiene efectos de ondulación en el modelo de objetos y la configuración de mapeo, y viceversa.

  7. Cachés: este enfoque también requiere el uso de cachés y contextos de objetos necesarios para mantener el estado del objeto y reducir los recorridos de la base de datos para los datos en caché. Estas memorias caché, si no se mantienen y se sincronizan en una implementación de niveles múltiples, pueden tener ramificaciones significativas en términos de precisión de datos y concurrencia. A menudo, los cachés de terceros o los cachés externos deben conectarse para resolver este problema, lo que agrega una gran carga a la capa de acceso a los datos.

Para obtener más información sobre nuestro análisis, puede leer: http://www.orasissoftware.com/driver.aspx?topic=whitepaper

No puedo hablar de otros ORM, solo Hibernate (para Java).

Hibernate me da lo siguiente:

  • Actualiza automáticamente el esquema de tablas en el sistema de producción en tiempo de ejecución. A veces, todavía tienes que actualizar algunas cosas manualmente.
  • Crea automáticamente claves externas que evitan escribir código incorrecto que está creando datos huérfanos.
  • Implementa la agrupación de conexiones. Múltiples proveedores de agrupación de conexiones están disponibles.
  • Almacena en caché los datos para un acceso más rápido. Múltiples proveedores de almacenamiento en caché están disponibles. Esto también le permite agrupar varios servidores para ayudarlo a escalar.
  • Hace que el acceso a la base de datos sea más transparente para que pueda transferir fácilmente su aplicación a otra base de datos.
  • Hacer consultas más fáciles de escribir. La siguiente consulta que normalmente requeriría que escriba ''join'' tres veces puede escribirse así:
    • "de Factura i donde i.customer.address.city =?" esto recupera todas las facturas con una ciudad específica
    • se devuelve una lista de objetos de Factura. Entonces puedo llamar a invoice.getCustomer (). GetCompanyName (); si los datos no están ya en la caché, la base de datos se consulta automáticamente en el fondo

Puede aplicar ingeniería inversa a una base de datos para crear el esquema de hibernación (no lo he probado yo mismo) o puede crear el esquema desde cero.

Por supuesto, hay una curva de aprendizaje como con cualquier tecnología nueva, pero creo que vale la pena.

Cuando sea necesario, puede bajar al nivel inferior de SQL para escribir una consulta optimizada.

Personalmente, no he tenido una gran experiencia con el uso de la tecnología ORM hasta la fecha. Actualmente estoy trabajando para una compañía que usa nHibernate y realmente no puedo continuar con eso. ¡Dame un proc almacenado y DAL cualquier día! Más código seguro ... pero también más control y código que es más fácil de depurar: según mi experiencia con una versión anterior de nHibernate, debe agregarse.

mi preocupación con los marcos ORM es probablemente lo que lo hace atractivo para muchos desarrolladores.

Nombrado que obvia la necesidad de ''preocuparse'' por lo que sucede en el nivel de DB. La mayoría de los problemas que vemos durante el día a día de nuestras aplicaciones están relacionados con problemas en la base de datos. Me preocupa un poco sobre un mundo que es 100% ORM que las personas no sabrán sobre qué consultas están llegando a la base de datos, o si lo hacen, no están seguros sobre cómo cambiarlas u optimizarlas.

{Me doy cuenta de que esta puede ser una respuesta contraversal :)}

Diría que si no se trata de objetos, no tiene mucho sentido usar un ORM.

Si sus tablas / columnas relacionales mapean 1: 1 con objetos / atributos, no tiene mucho sentido usar un ORM.

Si sus objetos no tienen ninguna relación 1: 1, 1: m ni m: n con otros objetos, no tiene mucho sentido usar un ORM.

Si tiene un SQL complejo y afinado a mano, no tiene mucho sentido usar un ORM.

Si ha decidido que su base de datos tendrá procedimientos almacenados como su interfaz, no tiene mucho sentido usar un ORM.

Si tiene un esquema heredado complejo que no se puede refactorizar, no tiene mucho sentido usar un ORM.

Así que aquí está lo contrario:

Si tiene un modelo de objeto sólido, con relaciones entre objetos que son 1: 1, 1: m ym: n, no tiene procedimientos almacenados, y al igual que el SQL dinámico que le dará una solución ORM, por supuesto. usa un ORM

Decisiones como estas son siempre una elección. Elija, implemente, mida, evalúe.

Aunque estoy de acuerdo con la respuesta aceptada casi por completo, creo que se puede modificar con alternativas ligeras en mente.

  • Si tiene SQL complejo y afinado a mano
  • Si sus objetos no tienen ninguna relación 1: 1, 1: m ni m: n con otros objetos
  • Si tiene un esquema heredado complejo que no se puede refactorizar

... entonces podría beneficiarse de un ORM liviano donde SQL no se oscurece o se abstrae hasta el punto en que es más fácil escribir su propia integración de base de datos.

Estas son algunas de las muchas razones por las que el equipo de desarrolladores de mi empresa decidió que necesitábamos hacer una abstracción más flexible para residir en la parte superior de JDBC.

Hay muchas alternativas de código abierto que logran cosas similares, y jORM es nuestra solución propuesta.

Yo recomendaría evaluar algunos de los candidatos más fuertes antes de elegir un ORM liviano. Son ligeramente diferentes en su enfoque de las bases de datos abstractas, pero pueden parecer similares desde una vista de arriba hacia abajo.

Si escribe su capa de acceso a datos a mano, básicamente está escribiendo su propia característica pobre ORM.

Oren Eini tiene un buen blog que resume qué características esenciales puede necesitar en su DAL / ORM y por qué escribir las suyas se convierte en una mala idea: http://ayende.com/Blog/archive/2006/05/12 /25ReasonsNotToWriteYourOwnObjectRelationalMapper.aspx

EDITAR: El OP ha comentado en otras respuestas que su base de código no está muy orientada a objetos. Tratar con el mapeo de objetos es solo una faceta de los ORM. El patrón de registro activo es un buen ejemplo de cómo los ORM siguen siendo útiles en escenarios donde los objetos asignan 1: 1 a tablas.