Sacándole el jugo al Patrón Repository 🥝

En este último tiempo, el patrón repository se está escuchando muy seguido en el mundo del desarrollo web y no es para menos, ya que le da una gran flexibilidad, mantenimiento y calidad a nuestro código.

En este artículo vamos a ver cómo podemos utilizarlo para que también brindé optimización a nuestro sistema.

El patrón repository

En otros artículos de Laravel Tip ya he comentado que el patrón de repositorios nos permite ser independientes del ORM (Eloquent en Laravel) o de la base de datos (MySQL, Postgresql, etc.).

Pero me quiero detener en el tema de Eloquent y el patrón repository. Algunas personas dicen que el patrón repository no es útil o es innecesario en Laravel, pero eso no es del todo cierto. Veamos cómo lo podemos utilizar para sacarle el jugo a este patrón.

El problema de los Modelos Eloquent

Los modelos de Eloquent nos promocionan TODOS los métodos necesarios para interactuar con la base de datos… pero… esperen un segundo… ¿es realmente necesario tener todos los métodos disponibles en todo momento?

La respuesta rápida sería un «si» rotundo, porque realmente es muy cómodo tener los métodos find, get, update, save, etc. a nuestra completa disposición. Pero supongamos que necesitamos hacer una exportación de ciertos datos a un archivo Excel, en este caso, ¿para que nos servirían los métodos de actualización e inserción?

Por ejemplo, para hacer una exportación (digamos, de productos), haríamos algo así:

Eloquent nos devolverá una colección, donde cada uno de sus elementos es un objeto del modelo Product. Y esto significa que tenemos acceso a los métodos update() y save() (entre muchos más) que realmente no los vamos a utilizar en una exportación. Por lo tanto, es costoso para nuestra RAM instanciar un modelo Eloquent, si solo vamos a realizar una operación de lectura (o escritura) únicamente.

Violación de Principio SOLID

Tener un objeto que nos brinde demasiados métodos que no vamos a necesitar, como son los objectos de Eloquent, estamos violando el principio SOLID de Segregación de la Interfaz. 

Este principio justamente nos dice que no debemos tener objetos con métodos que no vamos a utilizar.

Para saber más del Principio de Segregación de la Interfaz y todos los principios SOLID, te dejo un guía: https://www.laraveltip.com/guia-definitiva-de-principios-solid-explicados-con-laravel/

Utilizando el Patrón Repositorio

Como vimos, Eloquent nos brinda modelos para realizar tanto operaciones de escritura, como operaciones de lectura, y esto no es aconsejable cuando se busca optimización. Y aquí es donde entre en juego el patrón repositorio.

Lo aconsejable es tener una clase para las operaciones de lectura y otra clase para las de escritura. Y aquí es donde podemos aplicar los repositorios.

Refactorizando el ejemplo de la exportación de productos

Como los objetos de Eloquent nos permite hacer todo tipo de operaciones contra la base de datos, vamos a utilizar los repositorios para dividir las funcionalidades.

El ejemplo anterior lo podríamos reemplazar por:

Como vemos, escribimos un poco más de código pero, en compensación, ganamos legibilidad ya que el objecto repository tiene un método mucho más expresivo de lo que se esta haciendo y para que.

También vemos que en el constructor estamos inyectando una interfaz llamada ProductReportRepository, es una interfaz muy sencilla:

Y veamos como quedaría la clase concreta que es la encargada de hacer la consulta:

Y por ultimo, debemos «bindear» la interface con la clase concreta para que el controlador sepa que clase se esta utilizando, realmente. Así que, en el método register() del archivo AppServiceProvider.php, ponemos el siguiente código:

$this->app->bind(ProductReportRepository::class, ProductReportSqlRepository::class);

Y eso es todo. Ahora tenemos una clase que se dedica a obtener todos los registros de la base de datos.

Artículos que te pueden interesar:

Desacoplando Laravel de tu aplicación

Guía definitiva de Principios SOLID – Explicados con Laravel

Cómo utilizar Laravel con Docker La Guía Definitiva

Pro vs. Contras

Pros:

• No instanciamos grandes objetos con operaciones que no vamos a necesitar.
• La consulta es realmente rápida, ya que estamos utilizando SQL puro.
• Cumplimos el principio SOLID de Responsabilidad Única.
• Cumplimos el principio SOLID de Inversión de dependencias, ya que si en el futuro decidimos que esos datos no estén en una base de datos relacional, simplemente creamos un nuevo repositorio que implemente la interfaz y escribimos el código necesario para esta nueva implementación.
• Y todos los demás beneficios del patrón repository: flexibilidad, bajo acoplamiento y facilidad de testear.

Contras:

• Lleva un poco más de trabajo ya que escribimos más código y necesitamos crear clases adicionales: la interfaz del repositorio y la implementación del repositorio. Y además, registrarlas en el ServiceProvider.

Conclusión

No digo que debemos reemplazar automáticamente los modelos Eloquent por este tipo de solución. Es más, podríamos tener un repositorio que implemente un modelo Eloquent. Hay casos que necesariamente vamos a necesitar obtener datos y actualizarlos, y ahí Eloquent nos va a servir. Pero sin dudas, en proyectos importantes, debemos separar las operaciones de escritura de las operaciones de lectura.