Notice: Undefined index: excluded_urls in /web/hablemoslaravel/wp-content/plugins/super-progressive-web-apps/public/manifest.php on line 252
Sacándole el jugo al Patrón Repository 🥝 – Laravel Tip

Sacándole el jugo al Patrón Repository 🥝

Sacándole el jugo al Patrón Repository

Deja una respuesta

Comment as a guest.

  1. debemos separar las operaciones de escritura de las operaciones de lectura? Esto no me queda claro podría darme un ejemplo o explicación de como conseguir esto.

    1. Como va Enrique? Una operación de lectura le diga a una consulta a la base de datos que solo trae datos (un SELECT) y tu programa solo maneja esos datos para mostrarlos al usuario (o, como en el ejemplo del artículo, para exportarlos a un Excel). Y una operación de escritura es aquella que inserta, elimina o actualiza datos de la base de datos, por ejemplo una registración de un nuevo usuario.

      Cualquier duda, déjala por aquí. Saludos.

  2. Que tal, de mi parte he usado este patron, pero donde lo aprendí, vi que se creaba un repo por cada model, esta bien asi? Adicional a ello tenia un BaseRepo, de cual todos los repos extendian de este, en BaseRepo tenia las funciones como create, update, delete, etc.
    Esta bien que use un repo por cada model o tendria que cambiar algo?

    1. Hola Marco, como estas?
      Utilizar el patrón de esa forma te da el beneficio de poder testear y desacoplar la capa de persistencia. Si eso es lo que buscabas y tu proyecto lo requiere, esta perfecto.

      Ahora, si tu proyecto no va a cambiar la base de datos en el futuro, ni tampoco estas haciendo test automatizados sobre esto, entonces no los necesitas.

  3. en java tenemos los entity(modelo), reposity(métodos comunes), service(lógica de trabajo), controller (endpoint).

    ¿En laravel hacen la lógica en que seccion?

    1. Hola Omar, como estas?

      Donde poner la lógica de negocio en Laravel es una gran duda ya que Laravel no te dice donde debes hacerlo.
      Muchos dicen que el mejor lugar es en los Modelos porque son los que están más cerca de los datos. Pero las clases de los Modelos terminan siendo enormes y muy poco reutilizables.

      Para mí, lo mejor es meter toda la lógica en clases Services.

      Gracias por comentar.

      1. Hace poco empece a ver Laravel.
        quería implementar un patrón repository, con una capa DTO.
        En java dentro de los DTO podemos hacer la validación de tipos con etiquetados.
        Pero aquí no se si usar el Validate Form para hacer un objeto DTO. Y muchas otras cosas que me plantean dudas.
        Creo que me volveré ha Java.
        Gracias por tu respuesta.

        1. Como estas Omar?
          En Laravel lo mas importante son sus Routes, Controllers, Models y Views, luego el resto de clases (FormRequest, Scopes, etc.) son solo «herramientas» que el framework te brinda, pero el framework es bastante flexible para que utilices la arquitectura que quieras.
          Si quieres utilizar Laravel como venias acostumbra en Java, esta perfecto. Después depende de uno y del proyecto que estes haciendo, si quieres utilizar el resto de cosas que tiene el framework o no.

          Acá explico unos principios de otra arquitectura con Laravel, por si la quieres ver: https://www.laraveltip.com/desacoplando-laravel-de-tu-aplicacion/

          Saludos.

  4. Muy bien explicado, muchas gracias! Como dices la mayor ventaja es poder desacoplar la base de datos a la hora de hacer tests.

    Pero no sé, en mi opinión (https://youtu.be/uZp2HPbibA8) tenemos que dejarlo de lado y hacer test con la base de datos que laravel lo pone muy sencillo.

    1. Buen video Victor! Una aclaración, yo no soy partidario de usar una forma u otra. Como siempre, todo depende del caso.
      En un sistema chico/mediano, a full con Eloquent. Pero cuando empieza a crecer el sistema y aparecen nuevos problemas, tal vez es mejor empezar a pensar en refactorizar a repositorios.

  5. A mi opinión cada vez más les da por DIVIDIR TODO, la tendencia ha ido en DIVIDIR DIVIDIR DIVIDIR …
    Estas pinches convenciones solo «le convienen» a las grandes desarrolladoras, o cuando tienes equipos de trabajos grandes en proyectos grandes…

    LA UNICA GRAN VENTAJA es que de esa manera es más fácil mantener el código cuando VARIOS PROGRAMADORES LE METERAN MANO.

    Por eso para las grandes compañías que promueven esto, les conviene que los programadores se acostumbre a hacer TODO ESE TRABAJO DEMÁS, porque así ganarán las ventjas que ya he dicho. Y SE DE LO QUE HABLO PORQUE HE VISTO ESAS VENTAJAS DIRIGIENDO EQUIPOS DE DESARROLLO DE SOFTWARE en algunos proyectos.

    Pero para proyectos medianos, en los que solamente yo soy el programador, y solamente yo le voy a dar mantenimiento a ese sistema. SE ME HACE MUCHO MÁS TRABAJO implementar todo ese rollo y trabajar bajo dominios, y se van haciendo CARPETAS Y CARPETAS….

    Y lo explico: qué sentido tiene hacer un monton de carpetas para usar patrón repositorio, y un montón de carpetas para cada tipo de TRAIT, y cosas por el estilo… además eso ya se ve FEAMENTE ORGANIZADO EN TANTA «CARPETERÍA ANIDADA»

    En resumen:
    Como Gerente de Desarrollo y que vengo desde abajo con más de 15 años programando y COMO BIEN MENCIONAS EN ESTE POST … ES MÁS TRABAJO TRABAJAR ASÍ, pero si tu proyecto es grande y tienes varios programadores CONVIENE HACERLO!

    Si tu proyectos es tuyo y solo tuyo para un cliente al cual solo tu le desarrollas y le das mantenimiento, a veces NO CONVIENE HACER MAS TRABAJO, sino simplemente tener bien organizadito todo.

    Y sé que no va faltar el que venga a decir «que mal gerente eres y blablabla» por decir esto me van a odiar, PERO NO DIGO MAS QUE LA VERDAD aunque a algunos puristas les cale.

    Simplemente digo que estas cosas tienen ventajas y desventajas, y como decimos en México «Según el sapo, es la pedrada», habrá proyectos en que conviene trabajar un poco más haciendo folders y reestructurando mucho el codigo, PERO LA REALIDAD ES QUE NO ES UNA LEY PARA TODOS O QUE TODOS TENGAN QUE SER ASÍ…Aunque me odien y critiquen los puristas.

    1. Comparto! En proyectos chicos es mejor usar algo simple que te solucione el problema. Este blog esta hecho en wordpress 🤷🏻‍♂️
      Este artículo esta dirigido a personas que tienen curiosidad sobre el patrón repository y para que se puede usar.

      Saludos.

Sliding Sidebar

Matias Echazarreta

¡Hola!

Mi nombre es Matias Echazarreta.
Soy desarrollador web con más de 12 años de experiencia. Amante de Laravel, de los libros y del rock de los ’90. Te puedes comunicar conmigo  por trabajos de contratación, haciendo click aquí.

Nuestro Patreon

Desde Patreon puedes solicitar asesoria personalizado. ¡Ir a Patreon!

Suscríbete a nuestra lista de correo