E19: CRUD y ORM

Experiencias de un programador
E19: CRUD y ORM
/

Pros y contras del enfoque CRUD  y de los ORM (Object Relational Mapper), contado con historietas de la vida real. Esta es la continuación del episodio 18 así que te recomiendo que primero escuches ese.

Recursos citados o relacionados con el episodio:

Newsletters: Carlos Blé, Lean Mind

Canales de Telegram: Carlos Blé, Lean Mind 

About the Author
Developer/programador, autor, mentor, emprendedor, conferenciante, podcaster.

6 comments on “E19: CRUD y ORM

  1. Jorge dice:

    Me he quedado dando vueltas en mi cabeza a la frase «en programación orientada a objetos, se evitan los setters y getters».
    La Encapsulación, es una de las partes del paradigma de la programación orientada a objetos. No sé si fue un lapsus y te referías a otro asunto o es algo que se me escapa. ¿Podrías aclararlo?

    1. Tienes razón que se puede interpretar de varias formas Jorge, gracias por el apunte. Efectivamente es mejor envolver en getters y setters que dejar los campos de una clase públicos y accesibles a todo el mundo. No me refería a dejar los campos accesibles. Ahora bien, esta envoltura no es suficiente encapsulación para un diseño orientado a objetos. Idealmente los setters se usarán sólo para inyectar dependencias, nunca datos que representen el estado de la clase. Así la clase es dueña de la gestión de su estado. Por otra parte, cuantos menos getters haya, mejor. De esta forma nos obligaremos a cumplir con el principio «Tell, don’t ask», en el que a los objetos les pedimos que hagan cosas en lugar de pedirles que nos den sus datos. Es un buen tema sobre el que hablar en un futuro episodio. Saludos cordiales 🙂

  2. José Gilberto Trujillo Melián dice:

    Se puede usar un ORM como por ejemplo hibernate para que no «ayude» con la gestión de las transacciones (y con otras cosas como las abstracciones) y al mismo tiempo realizar las consultas con el lenguaje de consultas propio del ORM, hql en el caso de hibernate, para controlar en un grano más fino la extracción de datos. Si prescindimos por completo del uso de un ORM tengo la sensación que el tipo o sabor de base de datos que estemos usando (que al final es un detalle) puede acabar influyendo en el diseño y estableciendo una dependencia, que si bien no tiene porque ser sintáctica ( dura, de las de quito y peta) si que puede ser semántica (de las de esto funciona pero .. coño queda raro). Que me puedes decir perfectamente que eso también puede pasar con un ORM, pero es que casi cualquier camino que me pueda imaginar para prescindir de un ORM me llevaría a hacer mi propio ORM.

    Un saludo Carlos, no me hagas pensar que tengo sueño. Un abrazo.

    1. ¡Hola Jose! Efectivamente si vas a reinventar tu propio ORM, es mejor usar uno existente. Lo que me encuentro normalmente es que las consultas no son costosas de hacer y que hoy en día el SQL es bastante estándar. No recuerdo que me haya pasado en ningún proyecto que haya cambiado el motor de base de datos. Me quiere sonar que una vez se cambió de MySQL a PostgreSQL y fue muy fácil. Las herramientas son para usarlas cuando son útiles, sin duda. Lo que quería advertir es que el ORM no tiene que ser la herramienta que metamos siempre en todos los proyectos, sin más. ¡Gracias por el comentario!

  3. Omar Huanca dice:

    Hola Carlos.
    Me gusto el comentario respecto a no romper el encapsula miento, el uso de un método get en varias lugares de la aplicación considerando que en el tiempo ese atributo puede convertirse en opcional. Considerando que es un escenario en particular, Un saludo.

    1. Me alegro que te sirva Omar, ¿crees que te influirá en algo en tu forma de programar? Gracias!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *