Aprende en casa Ir a KODOTI
Aprende en casa KODOTI

¿Hacer uso de un ORM o SQL puro?

Comparación del enfoque tradicional versus el uso de un ORM para el acceso y manipulación de una base de datos.

Rodríguez Patiño, Eduardo
Rodríguez Patiño, Eduardo
2020-07-07 | 2,750 lecturas

En esta nueva entrada les voy a compartir mi experiencia haciendo uso de los ORM en el tiempo que llevo desarrollando y al final espero que puedan dejar un comentario ya sea a favor o encontra fundamentando su punto de vista.

¿QUÉ ES UN ORM?

Mapeo de objeto relacional o Oriented Relational Mapping (en inglés) es una técnica de programación que a través del paradigma de la programación orientada a objetos permite gestionar una base de datos evitando escribir consultas SQL. Por ejemplo, para acceder a tus tablas lo harás a través de objetos, métodos en vez de escribir queries de SQL como un select from users*.

VENTAJAS DE UN ORM

  • Agiliza el desarrollo.
  • Permite gestionar los cambios de la base de datos (Versionamiento).
  • Hace uso de la programación orientada a objetos y mediante esto podemos automatizar varias cosas.
  • Elimina la duplicidad de código SQL.
  • Es abstracto al motor de base de datos (según disponibilidad de los drivers de conexión). Es decir, trabaja con MySQL, SQL Server, Oracle porque a mi me da igual, tu no escribes código SQL, tu codificas usando POO.

DESVENTAJAS

  • Debemos invertir tiempo en entender como funciona la herramienta.
  • Puede llevarnos a obtener un mal performance si no lo usamos debidamente.
  • No puedes explotar las funcionalidades de un motor de base de datos.
  • Para queries del tipo reporte pueden ser algo tedioso.

EL DESARROLLO CLÁSICO

Como a la mayoría de ustedes, comencé haciendo uso de SQL y posteriormente store procedures para realizar las consultas, y los problemas que encontré conforme los proyectos iban creciendo fueron los siguientes:

  • Miles de store procedures para cada escenario, código inmantenible.
  • Si hay la necesidad de modificar o eliminar una columna, pues se tendría que actualizar los procedures relacionados.
  • El hacer uso de un store procedure me obligaba abrirlo para ver su contenido. Por ejemplo, si los tipos de datos son diferentes provocaría una excepción no controlada.
  • Las nuevas tablas, columnas nos obligaban a generar un script de pase a producción.
  • Los cambios de los procedures me obligaban a generar otro script de pase a producción.
  • Y así se me ocurren más cosas por las que ya pasé ..

ENTONCES, ¿QUÉ ES MEJOR?

Cualquiera de las 2 opciones son víables si tenemos claro los costos y beneficios de ambas partes. Personalmente no quiero volver al desarrollo clásico, ahora opto por comenzar un desarrollo haciendo uso de un ORM pero dado ciertas circunstancias y si el negocio lo amerita crearía un procedure para una tarea muy especifica. Por el otro lado, si el proyecto es pequeño no necesita la complejidad de un ORM o como también podría darse en el caso que el proyecto sea antiguo y bastante grande, e implementar un ORM sea muy costoso e imposible de mapear o las consultas que se hagan son demasiadas complejas.

¿POR QUÉ EXISTE RECHAZO?

Basicamente por 2 motivos:

  • Flojera a actualizarse.
  • Una FALSA creencia que son malos.

¿KODOTI QUE USA?

KODOTI es un proyecto mediano que usa Entity Framework Core 3 y hasta la fecha no hemos tenido, y creemos que no habrá la necesidad de hacer uso de un store procedure. Asimismo, no tenemos problemas de performance por hacer uso de un ORM.

Hay muchos factores que hemos considerado, no es solo el ORM, hay un tema de arquitectura de lado pero en esencia, no hubieramos hecho realidad el proyecto sin el uso de Entity Framework Core.

¿TE GUSTARÍA APRENDER A USAR ENTITY FRAMEWORK CORE 3?

Pues ya tenemos disponible un curso bastante completo de Entity Framework Core 3 a través de KODOTI en la cual no solo te enseñamos a usar esta herramienta, sino, también te compartimos tips de experiencia personal.


Estudia con nosotros

🚀 Mejora tus oportunidades laborales