By now, only Spanish version is available. Let me know if you are interested in the English one and I will make an effort to translate | Original version from the Deloitte Spain site.
La principal ventaja que nos aporta el uso de un ORM es la reducción de código a escribir en nuestra aplicación en comparación con las técnicas tradicionales de acceso a datos sobre RDBMS. La principal desventaja derivada del alto nivel de abstracción generado entre el modelo de entidades de nuestra aplicación y el RDBMS subyacente es que se tiende a “pasar por alto” toda la “magia” que el ORM genera para interactuar con la base de datos relacional física. Esto, en último término, puede llevar a importantes deficiencias en el rendimiento de las aplicaciones. Así, el rendimiento de nuestra aplicación no solo depende del ORM, sino del uso que hacemos de él.
Antes de comenzar las argumentaciones, hay que resaltar que la web está llena de partidarios y detractores del uso de ORMs. Además, existe un gran número de implementaciones de distintos proveedores, ofreciendo servicios con diferentes características. Por ello, la intención es solo la de aportar una visión al debate para facilitar la decisión de usar o no este tipo de componentes y en caso de utilizarse, qué características debería tener el ORM para encajar mejor en nuestra aplicación.
La decisión sobre usar o no un ORM debería girar en torno a dos ejes fundamentales:
- Complejidad en términos de Modelo de Entidades de nuestra aplicación.
- Rendimiento.
En base a estos dos ejes principales la recomendación sería la siguiente:
- Alta complejidad del Modelo de Entidades + Se acepta Rendimiento medio o bajo. Altamente recomendable. El ORM nos permitirá acelerar el desarrollo de la aplicación evitando la escritura repetitiva de código para ejecutar operaciones CRUD. Además, ya que el rendimiento de las consultas no es crítico, podremos confiar en el ORM para interactuar con el RDBMS sin dedicar mucho tiempo a supervisar las acciones ejecutadas.
- Alta complejidad del Modelo de Entidades + Rendimiento debe ser alto.Recomendable con condiciones. Como en el caso anterior, el ORM nos permitirá acelerar la implementación de nuestra aplicación, pero el modo de interactuar con dicho ORM deberá ser diseñado y supervisado por perfiles expertos, capaces de visionar y anticipar la forma en la que el ORM generará SQL eficiente.
- Baja complejidad del Modelo de Entidades + Rendimiento debe ser alto. No recomendable (salvo excepciones). En este caso aconsejaría el uso de una capa de acceso a datos más ligera con objetos personalizados para ejecutar queries optimizadas para cada operación CRUD. La existencia de pocas entidades no nos ahorrará mucho tiempo en la escritura de código y la exigencia de altos rendimientos nos obligará a supervisar tanto la interacción con el ORM como el código SQL generado.
No obstante, a modo de excepción, podríamos evaluar el uso de algún micro-ORM muy ligero tipo Dapper dependiendo de las especificaciones de nuestra aplicación y nuestros criterios personales. Éste nos proporcionará servicios simples de “mapeo” con uso de SQL personalizado.
- Baja complejidad del Modelo de Entidades + Se acepta Rendimiento medio o bajo. Opcional.Vaya por delante que pocas aplicaciones he encontrado con estas premisas a lo largo de mi carrera profesional. En todo caso, la elección con estas premisas será completamente opcional.
- Por último, la elección en casos intermedios dependerá de los criterios personales de cada uno valorando las diferentes ventajas y desventajas, además de restricciones concretas a aplicar en la solución a desarrollar.