¿Por qué debería utilizar un ORM? [cerrado]

Si tuviera que motivar a los "pros" de por qué usaría un ORM para la administración / el cliente, ¿cuáles serían las razones?

Intente mantener un motivo por respuesta para que podamos ver qué se vota como los mejores motivos

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.

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. =)

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.

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.

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.

Puede pasar a un software de base de datos diferente fácilmente porque está desarrollando una abstracción.

Para que su modelo de objetos y su modelo de persistencia coincidan.

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.

Minimizar la duplicación de consultas SQL simples.

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

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.

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.

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.

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.