¿Es ORM apto para proyectos complejos?

Question

No he comenzado el viaje de ORM todavía,

porque no estoy seguro de cómo funciona cuando el proyecto se vuelve muy complejo.

¿Cuál es su opinión o experiencia?

Answer 1

Cuando el proyecto se vuelve más complejo, es aún mejor, porque mantenemos todo en el mismo nivel de abstracción, en lugar de saltar de los objetos a SQL. Una vez hemos escrito nuestra propia capa en paralelo para desarrollar la aplicación (porque no podíamos usar ningún ORM tradicional), y cuanto más poderosa se volvía, más fácil se volvía la aplicación de administración.

Las preocupaciones sobre el rendimiento suelen estar sobrevaloradas. Por lo general, está en un lugar diferente, entonces es de esperar. Teníamos una capa de abstracción original escrita en Python, y funcionaba estupendamente. Lo que apestaba, era la biblioteca url, que tuvimos que reescribir en C. Realmente, siempre puedes optimizar las consultas, que son las más importantes al final, escribiendo SQL a mano en este momento, cuando lo ves, ese rendimiento lo necesita. Pero en la mayoría de las veces, no será necesario.

Answer 2

En mi opinión ORM construido para grandes proyectos, para minimizar el esfuerzo y el tiempo de desarrollo.

Pero si está desarrollando una aplicación que necesita el código de acceso de datos a muy alta velocidad, es necesario evitar el ORM como se puede porque ORM añadir una nueva capa en su aplicación

Answer 3

Ésta es subjetiva. Mi respuesta es específicamente sobre herramientas automatizadas de ORM.

tengo una objeción filosófica a herramientas ORM por las siguientes razones:
1- Una tabla no es y no debe ser necesariamente una correspondencia uno-a-uno a un objeto de negocio.
2- El código básico de CRUD/Business Object es aburrido de escribir, pero es fundamental para su aplicación. Prefiero estar en control y tener conocimiento de ello. (un poco del síndrome NIH)
3- Un nuevo desarrollador que ingrese tendrá más facilidad para aprender un modelo de objetos tradicional en comparación con cualquier sintaxis extraña creada por la herramienta ORM.

Answer 4

ORM. por definición, es mapeo relacional de objetos.

Esto significa que debe transformar los datos almacenados en una base de datos relacional en objetos utilizables por un lenguaje de programación orientado a objetos.

Los objetos pueden proporcionar algunos métodos que pueden implicar el procesamiento de datos y la búsqueda de otros objetos.

Aquí es donde comienzan los problemas.

El procesamiento de datos se puede implementar en el lado ORM (lo que significa que la carga de los datos de la base de datos, la aplicación de la envolvente objeto y la aplicación de los métodos en el lenguaje de programación que usa), o en el lado de base de datos (cuando el procesamiento de datos los comandos se emiten como una consulta a la base de datos).

Compare esto:

MyAccount->Transactions()->GetLast() 

Esto se puede implementar de dos maneras:

SELECT * 
FROM Accounts 
WHERE user_id = @me 

en $MyAccount

, entonces

SELECT * 
FROM Transactions 
WHERE account_id = @myaccount 

en un ar del lado del cliente rayo @Transactions

, luego $Transactions[-1] para obtener el último.

Esta es una forma ineficiente, y lo notará a medida que obtenga más datos.

Alternativamente, un inteligente ORM puede convertirlo en esto:

SELECT TOP 1 Transactions.* 
FROM Accounts 
JOIN Transactions 
ON  Transactions.Account = Accounts.id 
WHERE Accounts.UserID = @me 
ORDER BY 
     Transactions.Date DESC 

, pero tiene que ser un muy inteligente ORM.

Así que la respuesta a la pregunta "si usar ORM o no" es la respuesta a la pregunta "¿me permitirá ORM ejecutar las operaciones basadas en conjuntos en la base de datos si fuera necesario?"

Answer 5

Los ORM son ideales para proyectos grandes porque proporcionan una capa de protección contra los cambios en el lado de la base de datos, y aceleran el proceso de agregar nuevas características. Si el rendimiento se convierte en un problema, puede utilizar un método diferente para llegar a sus datos en la consulta donde se encuentra un cuello de botella, en lugar de optimizar a mano cada consulta en la aplicación.

Answer 6

usted no menciona qué plataforma que está utilizando, pero si quería leer un registro de una base de datos en .NET sin necesidad de utilizar un ORM, que tendría que:

1. Leer una cadena de conexión
2. abrir una conexión de base de datos
3. Abrir un objeto de comando contra la conexión
4. leer mi registro (por ejecutar una instrucción SQL en el objeto Command)
5. transformar ese registro a un objeto en mi idioma de su elección
6. Cerrar mi consulta
7. Cierre mi conexión

sonar complicado? Un ORM hace todas las mismas cosas automáticamente debajo de las cubiertas, y solo necesito algunas líneas de código. Además, dado que el ORM tiene conocimiento de su modelo de datos, a veces puede realizar optimizaciones como el almacenamiento en caché y la carga diferida.

Answer 7

Esta pregunta es difícil de responder a veces. Es posible que haya oído hablar del Object-Relational Impedance Mismatch antes; ese es el problema que intentan resolver las herramientas ORM, pero está plagado de problemas. Es una de esas situaciones en las que puede resolver el 90% del problema en muy poco tiempo, pero cada 1% adicional desde allí en adelante parece aumentar exponencialmente en complejidad debido a todas las dependencias.

marco

un ORM es una abstracción, y se convierte en una abstracción con fugas en varios puntos:

• consultas complejas/scripts que implican conceptos como UDT, Ctes, sugerencias de consulta, tablas temporales, funciones de ventanas, etc.

• Consultas optimizadas para el rendimiento. Como lo mencionó Quassnoi en su respuesta, los ORM están mejorando en esto, pero a menudo generan consultas subóptimas y, a veces, el efecto es muy notable.

• Gestión de transacciones: el patrón de unidad de trabajo solo puede llegar hasta usted cuando tenga que lidiar con grandes lotes de actualizaciones.

• Acciones entre bases de datos cruzadas o entre servidores. Hay soluciones, pero son solo eso: soluciones temporales. Ningún ORM que he visto realmente lo maneja bien.

• Múltiple-herencia de tablas - este es el única forma de herencia que es en realidad normalizada, y realmente no es tan difícil de manejar utilizando SQL puro y mapeo manual, pero creadores de mapas O/R son pésimo en ella. Para muchos de nosotros, la herencia de tabla única no es una alternativa aceptable.

Esas son algunas de las muchas áreas en las que los trazadores O/R parecen fallarnos. Una vez dicho esto, esto no significa que O/R Mappers no están "en forma" para proyectos grandes.

En mi opinión, ORM en general y O/R Mappers específicamente son casi vital para proyectos grandes. Ahorran enormes cantidades de esfuerzo y pueden ayudarte a obtener una aplicación en la puerta en una fracción del tiempo que te hubiera llevado de otra manera. Simplemente no resuelven el problema de entero. Debe estar preparado para perfilar su aplicación para ver lo que realmente está haciendo el ORM, y debe estar preparado para regresar al SQL puro cuando la situación lo requiera (es decir, en varias de las situaciones anteriores).

Algunos marcos, como Linq a SQL, esperan que haga esto y le proporcione instalaciones listas para ejecutar comandos o procedimientos almacenados en la misma conexión y en la misma transacción utilizada para las tareas "regulares" del asignador. L2S no es el único marco que le permite hacer esto, pero varios son más restrictivos y termina saltando muchos aros para obtener lo que necesita. Al elegir un ORM, creo que la capacidad de eludir la abstracción es una consideración importante, al menos hoy.

Creo que la mejor respuesta a esta pregunta es: Sí, son adecuados para grandes proyectos, siempre y cuando no dependa exclusivamente de ellos. Conozca los límites de su herramienta de ORM preferida, úsela como un ahorro de tiempo en el 90% de las instancias siempre que pueda, y asegúrese de que usted y su equipo comprendan lo que sucede realmente debajo de la capucha para aquellos casos en que la abstracción se filtra .

Answer 8

Los ORM son geniales si quiere sacar rápidamente la aplicación web para desarrollar clientes y ver si la gente realmente usa su producto.

http://www.youtube.com/watch?v=uFLRc6y_O3s

El último tema que Josh Berkus discute es "Runaway ORM". Compruébalo a las 37:20.