Cómo crear modelos de forma correcta

Bienvenidos a este post que trata sobre el cómo crear modelos de forma correcta para aplicaciones que utilizan el patrón de diseño MVC: Modelo, Vista, Controlador.

Una parte importante del trabajo dentro de un Framework MVC es el buen uso de los Modelos. 

El modelo es responsable de mantener el estado de la aplicación. A veces este estado es transitorio, y dura sólo un par de interacciones con el usuario. Otras veces el estado es permanente y se almacena fuera de la aplicación, a menudo en una base de datos.

Un modelo es algo más que datos; impone todas las reglas de negocio que se aplican a esos datos. Por ejemplo, si un descuento no debe aplicarse a los pedidos de menos de de 20 euros, el modelo aplicará la restricción. Esto tiene sentido; al poner la implementación de estas reglas de negocio en el modelo, nos aseguramos de que nada más en la aplicación puede hacer que nuestros datos no sean válidos. El modelo actúa como tanto un guardián como un almacén de datos.

Otra definición para el modelo es la siguiente: es el componente central del patrón (MVC). Es la estructura de datos dinámica de la aplicación, independiente de la interfaz de usuario. Gestiona directamente los datos, la lógica y las reglas de la aplicación.

En muchos casos, especialmente cuando uno comienza a trabajar en MVC, se cree que los modelos son únicamente para la gestión de la persistencia y la consulta de los datos de una base de datos (o de un repositorio)

Fundamentos

Antes de ahondar en los ejemplos y en los errores clásicos, nos gustaría mostrarte una imagen que puede ser de ayuda respecto de la forma en la que deberíamos construir nuestras aplicaciones usando el patrón descrito por Trygve Reenskaug (MVC)

 

La imagen, que es gentileza del Framework CakePHP, nos indica que una aplicación mal diseñada (Bad cake) tiene mucho código en los controladores y poco en las vistas y modelos. En la práctica, los controladores deberían servirnos principalmente para gestionar el Routing (las urls), interactuar con los modelos y despachar las vistas. En contraposición, una buena implementación (Good cake), debería contener más código en los modelos y menos en las vistas y controladores.

Volvamos un poco a lo que se mencionaba sobre el problema de los recién iniciados en MVC. Si bien es común que un modelo gestione datos de una base de datos, también sirve para gestionar «cosas» que no tienen relación con ello. Un ejemplo puede ser un modelo para un carro de compras. Es completamente factible llevar a cabo esta tarea sin persistencia en el DBMS (Database Management System). Bastaría con hacerlo con el objeto de sesión. Por otro lado, un modelo también podría encargarse de los pagos electrónicos, y luego apoyarse de otro que persista datos. Un modelo podría estar dedicado a la realización de cálculos específicos, otro del envío de notificaciones (SMS, Whatsapp, e-mail, etc), otro de la ejecución de tareas por shell dentro del servidor, y así sucesivamente.

¿Qué es lo más común?

Que las personas definan un modelo heredando de la clase del ORM (Object Relational Mapping) y, por ejemplo, en el caso de las notificaciones o el carro de compras, bastaría con que se utilizara una clase simple.

Vale, que aún no hay ejemplos porque nos quedan algunos fundamentos que debemos considerar.

DRY

Para muchos desconocido por sus siglas, pero viene del inglés Don’t Repeat Yourself. En buen castellano sería «No te repitas». ¿Qué significa esto? Significa que debemos gestionar cada «trozo de código» a su labor respectiva, en un único lugar. ¿Y qué tiene de malo copiar y pegar código? Cuando uno tiene mucho código repetido se rompe el principio DRY.

La repetición puede ser principalmente por desconocimiento de las herramientas que provee el Framework, o la clase de la que uno hereda. Por lo tanto, haz tu tarea de estudiante: revisa los métodos, la documentación y luego ponte manos a la obra para que no repitas cosas que ya están implementadas (lo que comúnmente llamamos reinventar la rueda)

Una vez que no tengas ruedas repetidas, verás que realizar modificaciones será una tarea sencilla, evitando así la fragilidad del código.

OOP

En términos de Orientación a Objetos, muchas veces no tenemos tan clara la diferencia entre el uso de la herencia, métodos estáticos y métodos dinámicos. Este tipo de temas los veremos en los ejemplos.

El ORM

Debemos familiarizarnos con la librería que gestiona la persistencia y las consultas al motor de bases de datos, en especial sus métodos, propiedades y los callbacks. En esto último quisiera detenerme un momento. Los callbacks son la analogía a lo que en un motor de base de datos se conoce como triggers (disparadores). Existen diferentes tipos de triggers, pero en generar se clasifican en los que se ejecutan antes de una acción y los que lo hacen después (before y after respectivamente)

El nuevo LiteRecord implementa callbacks para las acciones de creación (_beforeCreate, _afterCreate), para actualización (_beforeUpdate, _afterUpdate) y para guardar (_beforeSave, _afterSave)

En palabras simples, si el modelo encuentra un método _beforeAlgo, ejecutará dicha función antes de que se ejecute el método «Algo» (asumiendo que «Algo» puede ser Create, Save, Update). Por otro lado un _afterAlgo, se ejecutará luego que la función «Algo» haya finalizado.

Estos temas también los iremos tratando con casos cotidianos. Puedes checar su documentación en este enlace.

Traits 

Desde la versión de PHP 5.4 se implementan los Traits (rasgos, características) Es una buena estrategia para continuar con el principio DRY. De pronto tienes propiedades o métodos que son compartidos entre diferentes clases. Puedes extraer esos métodos en un trait y luego indicar que la clase implementa dichos «rasgos». Así tendrás un único lugar para ellos y finalmente, si hay menos código «innecesario o repetitivo», habrá menos errores y será más fácil de hacer mantención/corrección del mismo.