php - patron - laravel repository query

¿Cuál es el uso de repositorios e interfaces en Laravel?

Question

Después de desarrollar algunos proyectos usando Codeigniter desde hace 2 años, me quedé mirando para aprender Laravel.

Descargué algunos proyectos para aprender cómo están codificados. Según entendí, muchos de ellos están utilizando solo modelos, vistas y controladores, que es lo mismo que Codeigniter.

Pero un proyecto ha usado repositorios e interfaces. Es realmente difícil entender qué está pasando en ese proyecto. Entonces, ¿cuál es el uso de repositorios e interfaces en Laravel? ¿Cuándo debería usarlos?

Answer 1

Comencemos con uno más fácil, la interfaz:

Normalmente utiliza interfaces para implementar clases con los métodos necesarios: http://php.net/manual/en/language.oop5.interfaces.php

Los Contratos de Laravel son un conjunto de interfaces que definen los servicios principales proporcionados por el marco. Por ejemplo, un contrato Illuminate / Contracts / Queue / Queue define los métodos necesarios para trabajos en cola, mientras que el contrato Illuminate / Contracts / Mail / Mailer define los métodos necesarios para enviar correos electrónicos. https://laravel.com/docs/5.4/contracts#introduction

Cuando Laravel se está ejecutando, puede verificar si una clase implementa una interfaz especial:

if ($cls instanceof IInterface) {
$cls->interfaceFunction();
}

Como Laravel puede trabajar con colas, comprobará si el evento debe estar en cola o no, buscando una interfaz que salga.

Para informarle a Laravel que se debe transmitir un evento determinado, implemente la interfaz Iluminar / Contratos / Transmisión / DebieraBroadcast en la clase de evento. https://laravel.com/docs/5.4/broadcasting#defining-broadcast-events

Repositorio:

No encontré mucho sobre esto:

Nuestro repositorio no debe tener tanto conocimiento con respecto a quién les proporciona los datos o cómo lo están proporcionando. https://laravel.com/docs/5.4/contracts#loose-coupling

Pero encontré otra información en una página web:

un repositorio conectará las fábricas con pasarelas https://code.tutsplus.com/tutorials/the-repository-design-pattern--net-35804

El enlace le dará más información sobre los detalles.

Espero poder ayudarte :)

Answer 2

En primer lugar, los repositorios y las interfaces no son específicos de Laravel, sino que son estándares de codificación comunes en la mayoría de los lenguajes.

A continuación, los videos de Laracasts te serán útiles para comprender los conceptos básicos si no te importa gastar unos pocos dólares.

https://laracasts.com/lessons/repositories-and-inheritance

https://laracasts.com/series/object-oriented-bootcamp-in-php

Answer 3

En primer lugar, usar Repository and Interface en una aplicación más grande no solo es un beneficiario en Laravel, sino también en toda la tecnología para la codificación estándar y para la separación de preocupaciones.

De acuerdo con Microsoft (encontré la mejor explicación aquí)

Por qué usar el Repositorio:

Use un repositorio para separar la lógica que recupera los datos y los mapea en el modelo de entidad a partir de la lógica de negocios que actúa en el modelo. La lógica comercial debe ser independiente del tipo de datos que comprende la capa de fuente de datos. El repositorio media entre la capa fuente de datos y las capas comerciales de la aplicación. Consulta la fuente de datos para los datos, asigna los datos de la fuente de datos a una entidad comercial y persiste los cambios en la entidad comercial a la fuente de datos.
Un repositorio separa la lógica comercial de las interacciones con la fuente de datos subyacente o el servicio web. La separación entre los niveles de datos y de negocios tiene tres ventajas: centraliza la lógica de datos o la lógica de acceso al servicio web. Proporciona un punto de sustitución para las pruebas unitarias. Proporciona una arquitectura flexible que se puede adaptar a medida que evoluciona el diseño general de la aplicación. Hay dos formas en que el repositorio puede consultar entidades comerciales. Puede enviar un objeto de consulta a la lógica comercial del cliente o puede usar métodos que especifiquen los criterios comerciales. En este último caso, el repositorio forma la consulta en nombre del cliente. El repositorio devuelve un conjunto coincidente de entidades que satisfacen la consulta.

Para Interface, tienes muchas respuestas arriba, espero que lo hayas entendido.

Answer 4

Las interfaces son lo que cualquier clase implementadora debería llamar.

interface CanFlyInterface
{
public function fly();
}

Piense que es como programar sin preocuparse por la lógica.

if ($object instanceof CanFlyInterface) {
$obj->fly();
}

¡Ahora podríamos haber pasado un objeto Bird, o un objeto Airplane! ¡A PHP NO LE IMPORTA, siempre y cuando implemente la interfaz!

class Bird implements CanFlyInterface
{
public function fly()
{
return ''flap flap!'';
}
}
class Aeroplane implements CanFlyInterface
{
public function fly()
{
return ''roar! whoosh!'';
}
}

Tu otra pregunta, qué clase de Repositorio es. Es solo una clase que mantiene todas sus consultas DB en un solo lugar. Verifique esta interfaz como un ejemplo:

interface RepositoryInterface
{
public function insert(array $data);
public function update(array $data);
public function findById($id);
public function deleteById($id);
}

¡Espero que esto te aclare las cosas! Buena suerte con toda tu codificación PHP :-D

Answer 5

Trataré de explicar lo más claramente posible los dos conceptos.

Interfaces / Contratos

En general, las interfaces OOP se utilizan para describir qué métodos / funcionalidades ofrece la clase que implementa esa interfaz sin preocuparse por la implementación real .

Laravel usa Contracts principalmente para separar un servicio de la implementación real. Para ser más claros, hagamos un ejemplo

<?php
namespace App/Orders;
class OrdersCache
{
protected $cache;
public function __construct(/SomePackage/Cache/Memcached $cache)
{
$this->cache = $cache;
}
public function find($id)
{
if ($this->cache->has($id)) {
//
}
}
}

Como puede ver en esta clase, el código está estrechamente /SomePackage/Cache/Memcached a una implementación de caché (es decir, /SomePackage/Cache/Memcached ), por lo que si la API de esa clase de caché cambia nuestro código también debe cambiarse en consecuencia. Lo mismo sucede si queremos cambiar la implementación de la caché con otra (por ejemplo, redis).

En lugar de hacer eso, nuestro código podría depender de una interfaz que sea independiente de la implementación:

<?php
namespace App/Orders;
use Illuminate/Contracts/Cache/Repository as Cache;
class OrdersCache
{
public function __construct(Cache $cache)
{
$this->cache = $cache;
}
public function find($id)
{
if ($this->cache->has($id)) {
//
}
}
}

Ahora nuestro código no está acoplado con ninguna implementación específica porque Cache es realmente una interfaz. Básicamente en nuestra clase, estamos requiriendo una instancia de una clase que se comporte como se describe en la interfaz Cache , pero no estamos realmente interesados ​​en cómo funciona internamente. Si lo que queremos es cambiar la implementación de la memoria caché, podríamos escribir una clase que implemente la interfaz Cache sin cambiar ninguna línea de código en nuestra clase OrdersCache . Al hacerlo, nuestro código es más fácil de entender y mantener, y sus paquetes son mucho más reutilizables. Consulte la sección Unión suelta en la documentación de Laravel para obtener más ejemplos.

Interfaces y contenedor de servicio

Una de las características principales de Laravel es su Contenedor de servicios , que se utiliza para administrar dependencias y realizar inyecciones de dependencia. Por favor, eche un vistazo a la definición del contenedor de servicio de la documentación de Laravel.

Dependency Injection es ampliamente utilizado por Laravel también para vincular las interfaces a la implementación . Hagamos un ejemplo:

$app->bind(''App/Contracts/EventPusher'', ''App/Services/RedisEventPusher'');

Y que nuestra clase sea

<?php
namespace App/Http/Controllers;
use App/Contracts/EventPusher;
class EventsController extends Controller
{
protected $pusher;
public function __construct(EventPusher $pusher)
{
$this->pusher = $pusher;
}
}

Sin declarar nada más, básicamente estamos diciendo que cada vez que alguien necesite una instancia de EventPusher , por favor, Laravel, proporcione una instancia de la clase RedisEventPusher . En este caso, cada vez que se RedisEventPusher una instancia de su controlador, Laravel pasará una instancia de RedisEventPusher a su controlador sin especificar nada más.

Puede profundizar en eso mirando las Interfaces de enlace a la sección Implementación en la documentación de Laravel.

Repositorios

Repositorios es un concepto aplicable al patrón MVC independientemente de cualquier marco específico. Normalmente tiene su modelo que es la capa de datos (por ejemplo, interactúa directamente con la base de datos), su controlador que maneja la lógica de acceso a la capa de datos y su vista que muestra los datos proporcionados por el controlador.

Los repositorios en su lugar se pueden definir de la siguiente manera:

En pocas palabras, el patrón Repositorio es un tipo de contenedor donde se almacena la lógica de acceso a datos. Oculta los detalles de la lógica de acceso a datos de la lógica comercial. En otras palabras, permitimos que la lógica de negocios acceda al objeto de datos sin tener conocimiento de la arquitectura de acceso a datos subyacente.
Soruce : https://bosnadev.com/2015/03/07/using-repository-pattern-in-laravel-5

Para saber cómo usarlos dentro de Laravel, eche un vistazo a este https://bosnadev.com/2015/03/07/using-repository-pattern-in-laravel-5 .

Eso es todo, espero que ayude a aclarar tu mente.