deberías convertirlo en un wiki si quieres una encuesta
frankodwyer
+1 por convertirlo en un wiki si quieres una encuesta
cletus
16
¿Y las estafas?
Brian Matthews
4
Y tampoco cuchara. No, de verdad, hay una desventaja: rendimiento. Es mucho más fácil optimizar las consultas a la base de datos cuando no tiene que pasar por el ORM. (No me quejo, habiendo cambiado recientemente a ORM, estoy mayormente contento con él; para fines generales, ORM es el camino a seguir; pero mantenga alguna forma de ejecutar consultas más cercanas al metal si necesita el rendimiento)
Piskvor salió del edificio el
2
@ UğurGümüşhan, en mi humilde opinión, el principal beneficio de usar un ORM es hacer que los desarrolladores sean más productivos, al permitirles programar en el mismo idioma y paradigma de OO que usan en el resto de su aplicación. Los procedimientos almacenados no pueden proporcionar eso, cuando crean el código de desarrollador en el lenguaje de procedimiento almacenado RDBMS. Entonces no pueden hacer todo lo que puede hacer un ORM.
Bill Karwin
Respuestas:
53
Hacer que el acceso a los datos sea más abstracto y portátil. Las clases de implementación de ORM saben cómo escribir SQL específico del proveedor, por lo que usted no tiene que hacerlo.
Si bien estoy de acuerdo en que esta es una característica de los ORM, propondría que el caso de uso es bastante limitado. Realmente nunca he usado nada más que MySql y sqlite durante aproximadamente una década. Creo que probablemente sea un requisito muy poco común para la mayoría de los desarrolladores.
troelskn
40
@troelskn: Estoy de acuerdo, he usado muchos productos RDBMS, pero nunca más de uno o dos por proyecto. Entonces, la portabilidad no es el valor más práctico de abstraer SQL. Creo que muchos usuarios de ORM simplemente quieren evitar la codificación en SQL.
Bill Karwin
2
los proveedores salen con nuevas versiones / características todo el tiempo ... ¡solo se necesita gente interesante para escribir el dialecto y actualizarlo fácilmente!
dotjoe
5
Respuesta típica inútil. Me pregunto por qué está marcada como buena respuesta. Parece que el tipo que hace la pregunta solo intenta justificarle a su jefe que debería usar un ORM :) Mi pregunta sería más bien qué tipo de problema encontrará con Hibernate. stackoverflow.com/questions/6477170/…
user310291
2
@ user310291: El OP no preguntó por problemas o trampas, pidió los beneficios de usar un ORM. Por supuesto que hay pros y contras, pero preguntó por los pros. Francamente, me sorprende que esta respuesta haya sido aceptada y haya obtenido tantos votos a favor como lo hizo, porque no la consideraría como el principal beneficio de un ORM.
Bill Karwin
83
La razón más importante para usar un ORM es que pueda tener un modelo de negocio rico y orientado a objetos y aún así poder almacenarlo y escribir consultas efectivas rápidamente en una base de datos relacional. Desde mi punto de vista, no veo ninguna ventaja real que le brinde un buen ORM en comparación con otros DAL generados que no sean los tipos avanzados de consultas que puede escribir.
Un tipo de consulta en la que estoy pensando es una consulta polimórfica. Una simple consulta ORM puede seleccionar todas las formas en su base de datos. Obtienes una colección de formas. Pero cada instancia es un cuadrado, círculo o rectángulo según su discriminador.
Otro tipo de consulta sería aquella que busca ansiosamente un objeto y uno o más objetos o colecciones relacionados en una sola llamada a la base de datos. Por ejemplo, cada objeto de forma se devuelve con sus colecciones de vértices y laterales pobladas.
Lamento no estar de acuerdo con tantos otros aquí, pero no creo que la generación de código sea una razón suficientemente buena para ir con un ORM. Puede escribir o encontrar muchas buenas plantillas DAL para generadores de código que no tienen la sobrecarga conceptual o de rendimiento que tienen los ORM.
O, si cree que no necesita saber cómo escribir un buen SQL para usar un ORM, nuevamente, no estoy de acuerdo. Puede ser cierto que desde la perspectiva de escribir consultas únicas, confiar en un ORM es más fácil. Pero, con los ORM es demasiado fácil crear rutinas de bajo rendimiento cuando los desarrolladores no entienden cómo funcionan sus consultas con el ORM y el SQL al que se traducen.
Tener una capa de datos que funcione con varias bases de datos puede ser una ventaja. Sin embargo, no es uno en el que haya tenido que confiar tan a menudo.
Al final, tengo que reiterar que en mi experiencia, si no está utilizando las funciones de consulta más avanzadas de su ORM, hay otras opciones que resuelven los problemas restantes con menos aprendizaje y menos ciclos de CPU.
Ah, sí, algunos desarrolladores encuentran divertido trabajar con ORM, por lo que los ORM también son buenos desde la perspectiva de mantener felices a sus desarrolladores. =)
Bien dicho. Si bien el póster original buscaba específicamente "pros" y no "contras", he visto algunos SQL HORRIBLES creados al no comprender los impactos de CÓMO se usa ORM. Para mí, el mayor beneficio es para transacciones CRUD simples que son la mayoría de su código DAL para sistemas transaccionales. Creo que está dividiendo pelos entre ORM puro y otros métodos DAL generados. Creo que cualquier cosa que te ayude a traducir entre objetos y la base de datos podría considerarse ORM, es solo un modelo operativo diferente.
Doug Lampe
1
@Doug: creo que la distinción que buscaba era que un DAL simple consistía en poco más que CRUD SQL generado, mientras que un ORM contenía muchas más abstracciones, como propiedades de navegación, persistencia de la colección, lenguajes de consulta dedicados, cachés, etc. - Una mejor manera De expresar mi punto a la luz de su observación podría ser que, si bien es cierto que el uso de más funciones de un ORM le permite implementar más rápido, de ninguna manera es aceptable ignorar cómo funcionan esas funciones. Quizás porque las abstracciones de los ORM se filtran más que la mayoría. ( En.wikipedia.org/wiki/Leaky_abstraction )
Chuck
Por favor, explique esto un poco más: "si no está utilizando las funciones de consulta más avanzadas de su ORM, existen otras opciones que resuelven los problemas restantes". Además, como dice el creador de hibernate gavin king: "De hecho, sistemas como Hibernate están diseñados intencionalmente como" abstracciones con fugas "para que sea posible mezclar fácilmente SQL nativo cuando sea necesario. La fugas de la abstracción ORM es una característica, no un error ! " - reddit.com/r/programming/comments/2cnw8x/…
jungle_mole
1) Esto es viejo. En aquel entonces, los ORM tenían todas las funciones (cachés, consultas, procesamiento por lotes, etc.). En mi humilde opinión, las consultas polimórficas basadas en objetos eran la única característica de ORM que la generación de código (asignación explícita de ADO) no podía proporcionar fácilmente. 2) Si bien se dejaron intencionalmente algunos agujeros útiles, también hubo males necesarios y características avanzadas que crearon una alta curva de aprendizaje en los ORM. Entonces, mi respuesta fue usar la generación de código en lugar de ORM a menos que necesitara consultas avanzadas. *) En la actualidad, hay suficiente variedad en ORM como para que el conjunto de funciones adecuado para su equipo esté probablemente disponible. A mi equipo le gusta Linq2DB ahora.
Chuck
60
Acelerar el desarrollo. Por ejemplo, eliminar el código repetitivo como la asignación de campos de resultados de consultas a miembros de objetos y viceversa.
El código repetitivo es muy malo, pero ¿no podría construir una abstracción que elimine esto? Por ejemplo, puede tener un objeto de resultados de tabla / consulta que le devolverá filas con las que luego puede hacer cosas. Los ORM parecen dividir filas en instancias de clases individuales, en lugar de entrar en la abstracción elegida por la base de datos, que son tablas / filas de resultados de consultas. No estoy diciendo que esto signifique que los ORM no sean buenos, pero no estoy seguro de que esto solo sea una razón para usarlos.
Benjohn
@Benjohn, estoy de acuerdo en que la solución ORM trata las filas individuales como objetos, mientras que RDBMS trata los conjuntos de filas como una entidad. Hay cosas que puede hacer con la mentalidad de RDBMS que no puede hacer con una mentalidad de OO.
Bill Karwin
Esto es como comprar un auto completo solo para usar el maletero, hay muchas formas de evitar el trabajo repetitivo
mohas
15
Apoyar la encapsulación OO de las reglas comerciales en su capa de acceso a datos. Puede escribir (y depurar) reglas comerciales en el idioma de su aplicación de preferencia, en lugar de lenguajes torpes de activación y de procedimiento almacenado.
Sin embargo, ¿no desea tener sus reglas comerciales en la base de datos? Eso es un beneficio de una base de datos, ¿verdad? Varios clientes pueden usar la misma interfaz proporcionada por el DBMS. Si mucha de la lógica de su interfaz está bloqueada en el código ORM de un cliente en particular, no está en la base de datos y otros clientes no lo están usando. Indique las interrupciones de la oficina de recepción (un modelo de cliente se sale de la línea con el de otro).
Benjohn
1
@Benjohn, tiendo a poner simplemente reglas comerciales en la base de datos, pero las reglas más complejas no se forman fácilmente en restricciones declarativas. Por ejemplo, "el cliente obtiene un 10% de descuento en todo el pedido la primera vez que compra más de tres pares de pantalones de la misma marca". ¿Cómo pondría esa regla de negocio en la base de datos?
Bill Karwin
Es 2020, ya no veo a nadie usando procedimientos almacenados. Entonces, ¿sigues en pie?
ospider
Creo que lo que quiero decir es que la gente no usa procedimientos almacenados, usa código de aplicación. ¿Entendiste algo diferente?
Bill Karwin
10
Generación de código repetitivo para operaciones CRUD básicas. Algunos marcos ORM pueden inspeccionar los metadatos de la base de datos directamente, leer archivos de mapeo de metadatos o usar propiedades de clase declarativas.
En más de 30 años de trabajo con bases de datos, ni una sola vez tuve que hacer esto.
HLGEM
4
¡No significa que no sea posible! :)
Matt Fenelon
2
@HLGEM significa que está cerrando las opciones para el cliente. De hecho, podría suceder, en solo 3 años de trabajo con aplicaciones
web
1
Puede resultarle útil en caso de que desee ejecutar pruebas en una base de datos en memoria
Carlos Parraga
Es posible que varias instancias del mismo software usen diferentes bases de datos. Pero en realidad, el movimiento de datos existentes de un software de base de datos a otro rara vez ocurre. Y cuando lo hace, muchos ORM en realidad no lo ayudan con eso.
2018
4
Para que su modelo de objetos y su modelo de persistencia coincidan.
Tal vez para que su persistencia sea transparente para su modelo de objetos
S.Lott
4
Felicidad de desarrollo, en mi opinión. ORM abstrae muchas de las cosas básicas que tiene que hacer en SQL. Mantiene su base de código simple: menos archivos fuente para administrar y los cambios de esquema no requieren horas de mantenimiento.
Actualmente estoy usando un ORM y ha acelerado mi desarrollo.
La razón por la que lo estoy investigando es para evitar el código generado por las herramientas DAL de VS2005 (mapeo de esquemas, TableAdapters).
El DAL / BLL que creé hace más de un año funcionaba bien (para lo que lo había construido) hasta que alguien más comenzó a usarlo para aprovechar algunas de las funciones generadas (que no tenía idea de que estaban allí)
Parece que proporcionará una solución mucho más intuitiva y limpia que la solución DAL / BLL de http://wwww.asp.net
Estaba pensando en crear mi propio generador de código SQL Command C # DAL, pero el ORM parece una solución más elegante
A medida que mejoran las herramientas para ORM, es más fácil determinar la exactitud de sus consultas más rápidamente a través de pruebas y errores de tiempo de compilación.
La compilación de sus consultas ayuda a los desarrolladores a encontrar errores más rápidamente. ¿Correcto? Correcto. Esta compilación es posible porque los desarrolladores ahora están escribiendo consultas en código usando sus objetos o modelos de negocios en lugar de solo cadenas de SQL o declaraciones similares a SQL.
Si utiliza los patrones de acceso a datos correctos en .NET, es fácil probar unitariamente la lógica de su consulta en las colecciones de memoria. Esto acelera la ejecución de sus pruebas porque no necesita acceder a la base de datos, configurar datos en la base de datos o incluso generar un contexto de datos completo. [EDITAR] Esto no es tan cierto como pensé que era como unidad las pruebas en la memoria pueden presentar desafíos difíciles de superar. Pero sigo encontrando estas pruebas de integración más fáciles de escribir que en años anteriores. [/ EDITAR]
Esto es definitivamente más relevante hoy que hace unos años cuando se hizo la pregunta, pero ese solo puede ser el caso de Visual Studio y Entity Framework donde reside mi experiencia. Conecte su propio entorno si es posible.
Extraiga el sql el 95% del tiempo para que no todos en el equipo necesiten saber cómo escribir consultas específicas de bases de datos súper eficientes.
Creo que hay muchos puntos buenos aquí (portabilidad, facilidad de desarrollo / mantenimiento, enfoque en el modelado de negocios OO, etc.), pero cuando intenta convencer a su cliente o gerencia, todo se reduce a cuánto dinero ahorrará al usar un ORM .
Haga algunas estimaciones para tareas típicas (o incluso proyectos más grandes que podrían estar por venir) y obtendrá (¡con suerte!) Algunos argumentos para cambiar que son difíciles de ignorar.
Ugh. Usamos Net Tiers en un gran proyecto comercial, y recomiendo encarecidamente no usarlo. El problema es que no se puede componer. ¿Quiere consultar objetos Foo y Bar? No puede escribir uniones, debe emitir consultas separadas para cada tipo de objeto que desee. Esto da como resultado muchas llamadas a la base de datos, lo que puede afectar el rendimiento y la atomicidad. Malo malo malo. Mantente alejado.
Judah Gabriel Himango
0
convéncelos de cuánto tiempo / dinero ahorrará cuando se produzcan cambios y no tiene que volver a escribir su SQL, ya que la herramienta ORM lo hará por usted
Creo que una de las desventajas es que ORM necesitará alguna actualización en su POJO. principalmente relacionado con el esquema, la relación y la consulta. Entonces, el escenario en el que se supone que no debe realizar cambios en los objetos del modelo, podría deberse a que se comparte entre más personas que en el proyecto o en el cliente y servidor en blanco y negro. por lo que en tales casos deberá dividirlo en dos niveles, lo que requerirá esfuerzos adicionales.
Soy un desarrollador de Android y, como saben, las aplicaciones móviles no suelen tener un tamaño enorme, por lo que este esfuerzo adicional para segregar el modelo puro y el modelo afectado por el organismo no parece valer la pena.
Entiendo que esa pregunta es genérica. pero las aplicaciones móviles también se incluyen en un paraguas genérico.
Respuestas:
Hacer que el acceso a los datos sea más abstracto y portátil. Las clases de implementación de ORM saben cómo escribir SQL específico del proveedor, por lo que usted no tiene que hacerlo.
fuente
La razón más importante para usar un ORM es que pueda tener un modelo de negocio rico y orientado a objetos y aún así poder almacenarlo y escribir consultas efectivas rápidamente en una base de datos relacional. Desde mi punto de vista, no veo ninguna ventaja real que le brinde un buen ORM en comparación con otros DAL generados que no sean los tipos avanzados de consultas que puede escribir.
Un tipo de consulta en la que estoy pensando es una consulta polimórfica. Una simple consulta ORM puede seleccionar todas las formas en su base de datos. Obtienes una colección de formas. Pero cada instancia es un cuadrado, círculo o rectángulo según su discriminador.
Otro tipo de consulta sería aquella que busca ansiosamente un objeto y uno o más objetos o colecciones relacionados en una sola llamada a la base de datos. Por ejemplo, cada objeto de forma se devuelve con sus colecciones de vértices y laterales pobladas.
Lamento no estar de acuerdo con tantos otros aquí, pero no creo que la generación de código sea una razón suficientemente buena para ir con un ORM. Puede escribir o encontrar muchas buenas plantillas DAL para generadores de código que no tienen la sobrecarga conceptual o de rendimiento que tienen los ORM.
O, si cree que no necesita saber cómo escribir un buen SQL para usar un ORM, nuevamente, no estoy de acuerdo. Puede ser cierto que desde la perspectiva de escribir consultas únicas, confiar en un ORM es más fácil. Pero, con los ORM es demasiado fácil crear rutinas de bajo rendimiento cuando los desarrolladores no entienden cómo funcionan sus consultas con el ORM y el SQL al que se traducen.
Tener una capa de datos que funcione con varias bases de datos puede ser una ventaja. Sin embargo, no es uno en el que haya tenido que confiar tan a menudo.
Al final, tengo que reiterar que en mi experiencia, si no está utilizando las funciones de consulta más avanzadas de su ORM, hay otras opciones que resuelven los problemas restantes con menos aprendizaje y menos ciclos de CPU.
Ah, sí, algunos desarrolladores encuentran divertido trabajar con ORM, por lo que los ORM también son buenos desde la perspectiva de mantener felices a sus desarrolladores. =)
fuente
Acelerar el desarrollo. Por ejemplo, eliminar el código repetitivo como la asignación de campos de resultados de consultas a miembros de objetos y viceversa.
fuente
Apoyar la encapsulación OO de las reglas comerciales en su capa de acceso a datos. Puede escribir (y depurar) reglas comerciales en el idioma de su aplicación de preferencia, en lugar de lenguajes torpes de activación y de procedimiento almacenado.
fuente
Generación de código repetitivo para operaciones CRUD básicas. Algunos marcos ORM pueden inspeccionar los metadatos de la base de datos directamente, leer archivos de mapeo de metadatos o usar propiedades de clase declarativas.
fuente
Puede pasar a un software de base de datos diferente fácilmente porque está desarrollando una abstracción.
fuente
Para que su modelo de objetos y su modelo de persistencia coincidan.
fuente
Felicidad de desarrollo, en mi opinión. ORM abstrae muchas de las cosas básicas que tiene que hacer en SQL. Mantiene su base de código simple: menos archivos fuente para administrar y los cambios de esquema no requieren horas de mantenimiento.
Actualmente estoy usando un ORM y ha acelerado mi desarrollo.
fuente
Minimizar la duplicación de consultas SQL simples.
fuente
La razón por la que lo estoy investigando es para evitar el código generado por las herramientas DAL de VS2005 (mapeo de esquemas, TableAdapters).
El DAL / BLL que creé hace más de un año funcionaba bien (para lo que lo había construido) hasta que alguien más comenzó a usarlo para aprovechar algunas de las funciones generadas (que no tenía idea de que estaban allí)
Parece que proporcionará una solución mucho más intuitiva y limpia que la solución DAL / BLL de http://wwww.asp.net
Estaba pensando en crear mi propio generador de código SQL Command C # DAL, pero el ORM parece una solución más elegante
fuente
Recopilación y prueba de consultas.
A medida que mejoran las herramientas para ORM, es más fácil determinar la exactitud de sus consultas más rápidamente a través de pruebas y errores de tiempo de compilación.
La compilación de sus consultas ayuda a los desarrolladores a encontrar errores más rápidamente. ¿Correcto? Correcto. Esta compilación es posible porque los desarrolladores ahora están escribiendo consultas en código usando sus objetos o modelos de negocios en lugar de solo cadenas de SQL o declaraciones similares a SQL.
Si utiliza los patrones de acceso a datos correctos en .NET, es fácil probar unitariamente la lógica de su consulta en las colecciones de memoria. Esto acelera la ejecución de sus pruebas porque no necesita acceder a la base de datos, configurar datos en la base de datos o incluso generar un contexto de datos completo. [EDITAR] Esto no es tan cierto como pensé que era como unidad las pruebas en la memoria pueden presentar desafíos difíciles de superar. Pero sigo encontrando estas pruebas de integración más fáciles de escribir que en años anteriores. [/ EDITAR]
Esto es definitivamente más relevante hoy que hace unos años cuando se hizo la pregunta, pero ese solo puede ser el caso de Visual Studio y Entity Framework donde reside mi experiencia. Conecte su propio entorno si es posible.
fuente
Extraiga el sql el 95% del tiempo para que no todos en el equipo necesiten saber cómo escribir consultas específicas de bases de datos súper eficientes.
fuente
Creo que hay muchos puntos buenos aquí (portabilidad, facilidad de desarrollo / mantenimiento, enfoque en el modelado de negocios OO, etc.), pero cuando intenta convencer a su cliente o gerencia, todo se reduce a cuánto dinero ahorrará al usar un ORM .
Haga algunas estimaciones para tareas típicas (o incluso proyectos más grandes que podrían estar por venir) y obtendrá (¡con suerte!) Algunos argumentos para cambiar que son difíciles de ignorar.
fuente
Niveles .net usando plantillas de código smith
http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1
Por qué codificar algo que también se pueda generar.
fuente
convéncelos de cuánto tiempo / dinero ahorrará cuando se produzcan cambios y no tiene que volver a escribir su SQL, ya que la herramienta ORM lo hará por usted
fuente
Creo que una de las desventajas es que ORM necesitará alguna actualización en su POJO. principalmente relacionado con el esquema, la relación y la consulta. Entonces, el escenario en el que se supone que no debe realizar cambios en los objetos del modelo, podría deberse a que se comparte entre más personas que en el proyecto o en el cliente y servidor en blanco y negro. por lo que en tales casos deberá dividirlo en dos niveles, lo que requerirá esfuerzos adicionales.
Soy un desarrollador de Android y, como saben, las aplicaciones móviles no suelen tener un tamaño enorme, por lo que este esfuerzo adicional para segregar el modelo puro y el modelo afectado por el organismo no parece valer la pena.
Entiendo que esa pregunta es genérica. pero las aplicaciones móviles también se incluyen en un paraguas genérico.
fuente