¿Qué tipo de proyectos de desarrollo web se benefician al usar ORM?

10

Comenzaré diciendo que he realizado el 95% del trabajo de mi base de datos usando SQL. Recientemente, hice una investigación de varios ORM, como NHibernate y Doctrine.

Puedo ver las ventajas de no necesitar saber mucho sobre SQL y la portabilidad de la base de datos que proporciona un ORM. Pero también puedo ver que conocer SQL hará que trabajar con un ORM sea más efectivo y solo puedo pensar una vez en mi carrera que el mayor cambio de una aplicación sería el proveedor de la base de datos.

Debido a que me siento muy cómodo escribiendo SQL y aparentemente no me estoy dando cuenta de los beneficios a menudo enseñados de usar un ORM, mi pregunta para los usuarios de ORM es esta:

¿Qué tipo de proyectos de desarrollo web se benefician más del uso de ORM?

php asp.net sql ruby-on-rails orm Fred Wilson
fuente
3
La respuesta es "Todos ellos". Pero eso probablemente no sea lo que quieres saber. Es posible que desee refinar su pregunta para pedir información más específica.
S.Lott
1
Para mí, SQL es actualmente más fácil de producir, pero eso es solo debido a mi aclimatación (o ignorancia). He leído que ORM no siempre es la mejor opción porque es más lento que el SQL normal; Sin embargo, muchos desarrolladores han declarado que esto generalmente no es importante. Tengo curiosidad sobre los proyectos que son más adecuados para ORM. Puedo ver que la mayoría de las respuestas serán "todas", y eso también está bien. No estoy buscando una respuesta específica. :)
Fred Wilson
Si no solicita más detalles, no aprenderá mucho.
S.Lott

Respuestas:

5

(Casi) todas las aplicaciones se benefician de ORM.

Primero, no estoy de acuerdo con las ventajas que enumera para ORM .

  • Usar ORM no necesariamente significa que no necesita saber SQL. El conocimiento de SQL ayudará a comprender qué está haciendo realmente la herramienta ORM, lo que es especialmente útil durante la depuración. Además, es posible que se requiera SQL para desarrollar consultas complejas que están más allá de la capacidad de su ORM elegido.
  • Y como usted dice, la portabilidad rara vez es una preocupación en la vida real.

En cambio, los beneficios reales de ORM son:

  • ORM ahorra tiempo al programador porque ahorra escribir toneladas de lógica CRUD en SQL
  • muchos ORM incluyen lógica de almacenamiento en caché compleja, etc. que es difícil de escribir y depurar. Además de ahorrar tiempo, esto puede mejorar la confiabilidad y la facilidad de mantenimiento de su aplicación (o al menos ahorrarle el tiempo que le tomaría lograr los mismos resultados)
  • Los mejores ORM tienen una comunidad de usuarios que desarrollan, mantienen y respaldan activamente el producto. La comunidad en torno al SQL personalizado está, en el mejor de los casos, algo menos enfocada en los problemas que necesitamos resolver.

Como comenta, una desventaja de ORM es la pérdida de rendimiento. Sin embargo, esto generalmente se puede compensar gastando más hardware.

Por lo general, el tiempo del programador es más costoso que el hardware, por lo que ORM es generalmente una buena opción en lugar de codificar manualmente SQL.

ORM es mejor para aplicaciones con mucha lógica de base de datos CRUD bastante simple. ORM es menos efectivo para :

  • Aplicaciones que necesitan poco o ningún acceso a la base de datos.
  • Aplicaciones que dependen en gran medida de consultas complejas y muy poca lógica CRUD simple
  • Situaciones donde el rendimiento es crítico, pero donde no hay posibilidad de implementar hardware más rápido

En mi experiencia, estas situaciones son raras. De ahí mi respuesta.

Kramii
fuente
"Usar ORM no necesariamente significa que no necesitas saber SQL". - Tan verdadero. Una de las ventajas que veo en un entorno de equipo es que podemos concentrar el conjunto de habilidades SQL para que no todos los desarrolladores que trabajan en la capa empresarial tengan que ser expertos.
Fred Wilson
1
Para consultas complejas, siempre puede volver a SQL y escribir una consulta SQL.
harsimranb
4

Me siento cómodo escribiendo SQL también. También me siento mucho más cómodo al no tener que escribir ningún SQL en absoluto, y al no preocuparme por conectar, desconectar, agrupar, etc. a una base de datos.

Entonces ... responderé lo negativo de tu pregunta. Los únicos proyectos de desarrollo web que NO se benefician de un ORM son aquellos que no hablan con una base de datos. Que creo que son minoría (si existe).

Otávio Décio
fuente
+1: También me considero muy competente en sql, pero aún prefiero un OR / M. De hecho, diría que definitivamente necesita tener un controlador en sql para hacer un buen uso de un OR / M, de lo contrario, cuando la abstracción se filtre, nunca encontrará el problema. "no necesita saber mucho SQL" no es una característica. Para mí, todo se trata de ganancias de productividad y hacer que el compilador encuentre los problemas, no el tiempo de ejecución, y los OR / M (especialmente los genéricos más nuevos / basados ​​en linq son geniales).
Brook
@Brook - Estoy totalmente de acuerdo. Usar un OR / M no significa que el conocimiento de SQL sea opcional.
Otávio Décio
2

Basado en mi experiencia con ASP.NET WebForms, propondría que los proyectos web que usan marcos web con estado sean los más beneficiados al usar un ORM.

Con un marco de estado, el marcado se genera automáticamente detrás de escena, según la jerarquía de los controles activos del servidor. Es tentador hacer que esos controles carguen y persistan su estado automáticamente en la base de datos. Aquí es donde ORM ayuda.

De alguna manera, abstrae el final de la canalización (salida HTML) y, naturalmente, es atractivo tratar con el principio (fuente de datos) de la misma manera para que solo permanezca dentro de la lógica de su negocio en el código de la aplicación.

No es que no esté diciendo que esta es una buena manera de hacer las cosas. Es justo donde ORM encaja naturalmente.


fuente
2

En aplicaciones donde tiene un modelo de objeto grande y muy conectado, un ORM le evita escribir las mismas combinaciones una y otra vez.

Otro beneficio es la carga diferida, donde desea que una API devuelva un gráfico de objeto donde el cliente de la API solo usará un subconjunto de ese gráfico.

Paul Sanwald
fuente
1

Creo que estás confundiendo un ORM con un DBAL .

El concepto al que se refiere es una Capa de abstracción de base de datos (DBAL) que le permite escribir "sql" portátil que no depende del sistema de base de datos subyacente.

Un ORM por otro lado (que (¿casi?) Siempre se construye encima de un DBAL):

Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. (Wikipedia)

En pocas palabras, un ORM le permite convertir datos de una base de datos plana en una representación de objeto inflado.

Craige
fuente
Gracias por la aclaración. La razón principal para pasar a ORM es centrarme más en OOP y alejarme de escribir tanto SQL si tiene sentido para algunos proyectos.
Fred Wilson
1

Los proyectos que no se beneficiarían de ORM serían:

  • los que no están orientados a objetos;
  • unos, que no necesitan persistir datos;
  • los que usan DB orientado a objetos, por lo tanto no necesitan una capa de mapeo adicional;
  • los que usan una solución NoSQL no relacional;
vartec
fuente