Curso de diseño y arquitectura en Laravel

Un breve vídeo de presentación que explicará qué vamos a aprender en este curso y por qué queremos aprender arquitectura en Laravel.

Trabajar con un framework como Laravel ya supone una ventaja con respecto a trabajar con PHP "nativo" ¿Pero estás seguro que pones todo de tu parte para conseguir aplicaciones con un buen diseño y arquitectura?

En esta clase te explicamos las piezas que puedes usar en Laravel para conseguir que tus aplicaciones tengan un mejor diseño y arquitectura.

Vamos a comenzar viendo un controlador que requiere una mejora de diseño, porque se ocupa de muchas cosas, haciéndose demasiado grande y dificultando la reutilización. Está pidiendo a gritos que creemos un servicio.Qué es un servicio y cómo organizar el código de las aplicaciones en servicios, para descargar a los controladores.

Explicamos con más detalle qué son los servicios y cómo los vamos a crear en Laravel. Cómo podemos organizar los servicios y crear clases sobre las que implementaremos más adelante servicios.

Vamos a separar las responsabilidades de negocio del controlador gordo que vimos anteriormente en un servicio que se encargue de las partes que no deberían estar en el controlador. Veremos cómo conseguimos una estructura mejor para nuestro código, aligerando el controlador y pudiendo reutilizar la lógica del servicio.

En este vídeo proponemos una práctica para los estudiantes. Vamos a mostrar un controlador que es candidato a separar algunas de sus funciones a un servicio, de modo que luego podamos reutilizar en otras partes de la aplicación. Veremos también la solución final de esta práctica de implementación de un servicio.

Veremos qué es el service container y cómo, quizás sin saberlo, ya lo venimos usando en las aplicaciones Laravel de manera frecuente. Veremos cómo puedes recibir instancias de clases nativas de Laravel pero además de nuestros servicios creados de manera específica en una aplicación.

Vamos a hacer un rápido repaso, o introducción para los que no los conozcan, de algunos principios de diseño de software sobre los que vamos ha hablar bastante, ya que son promovidos directamente por el service container de Laravel.

En este vídeo realizaremos un nuevo ejemplo de servicio para que veamos cómo podemos inyectarlo en un controlador de diversos modos, básicamente mediante el constructor o cualquier otro método.

Qué son los service providers, qué métodos incluyen y cuál es el objetivo de cada uno. Cómo crear service providers y cómo registrar los service providers creados.

Ahora vamos a ver cómo configurar el contenedor de servicios de Laravel para decirle qué clase concreta debe instanciar cuando se solicite la inyección de una interfaz en alguna pieza del framework.

Con el objetivo de ampliar los casos de uso de la inyección de dependencias, vamos a ver cómo realizar un middleware e inyectarle una interfaz, que se resolverá mediante el binding realizado en el service provider.

Ahora vamos a aprender otro tipo de binding un poco más avanzado, que nos permite definir qué clase debe instanciarse cuando se realiza la inyección en otra clase en particular. De este modo podemos decirle al service container que determinadas clases de la aplicación requieren que se instancie un objeto de una clase distinta a otras clases de la aplicación.

En este vídeo vamos a ver un nuevo ejemplo de aplicación de la inyección de dependencias, para pasar de un controlador que es poco testable a un controlador que sí es testable.

Ahora vamos a ver cómo podríamos crear nuestra propia clase de servicio Fake que queremos usar en los tests. Vemos un procedimiento bastante manual pero efectivo, que nos permitirá entender las ventajas de la inyección de dependencias y la sobreescritura de los bindings que hemos realizado en el contenedor de servicios de Laravel.

Tenemos un caso especial de binding que el contenedor de servicios no es capaz de resolver y consiste en los casos en los que la clase inyectada recibe en el constructor un valor escalar, de un tipo primitivo como entero o cadena. Para resolver estos casos vamos a aprender a usar el binding mediante una función anónima.

Un tipo sencillo de binding que funciona de manera condicional. Si no estaba antes se crea y si ya estaba simplemente se ignora

Además de configurar el service container mediante los service providers podemos usar los atributos. Estas anotaciones nos permiten definir los bindeos a nivel de clase o interfaz, de una manera muy sencilla.

Es un tipo de binding que funciona como el patrón singleton, asegurando que solamente exista una única instancia de la clase, entregando a todos los lugares donde se inyecte el mismo objeto.

Un caso especia de singleton que nos asegura que la misma instancia solamente se use en un único request o la ejecución de un único job, sobre todo importante cuando usas programación con workers.

Vemos cómo configurar el singleton y scoped a nivel de atributo, mostrando un nuevo ejemplo de utilidad de singleton.

Aparte de todos los usos que hemos visto del contenedor de servicios, que se han centrado en la inyección de dependencias, vamos a ver que también podemos acceder al service container de numerosas maneras y solicitarle instancias de clases.

Vamos a ver otro uso relacionado con el del vídeo anterior que nos permite usar el contenedor de servicios para solicitarle instancias que no han sido previamente bindeadas, indicando la configuración al vuelo.

En este vídeo vamos a conocer los Contextual Attributes que nos permiten definir anotaciones mediante las cuales inyectar diversos tipos de clases nativas del framework con configuraciones diversas, o incluso crear nuestras propias anotaciones para incrementar este tipo de shortcuts para inyectar dependencias.

Ahora mostramos una serie de usos diversos de service providers, más allá de la configuración del service container. Pondremos ejemplos variados y representativos de cosas que podrías querer configurar en el método boot.

En este vídeo vamos a ver un nuevo ejemplo de testing de funcionalidad (feature) de Laravel, en el que vamos a profundizar un poco para poder usar las utilidades del framework que nos habilita la inyección de dependencias.

La librería Mockery está integrada en Laravel y la podemos usar también para crear mocks de nuestros servicios.

A la hora de usar mocks podemos configurar las expectativas que tenemos sobre los servicios que se invocarían al hacer los test. Explicamos las configuraciones de expectatios que normalmente querrás hacer sobre tus propios servicios.

Aunque ya uses fachadas, vamos a ver en este vídeo sus fundamentos, analizando los problemas de diseño que tienen los métodos estáticos y por qué las fachadas, pese a funcionar con métodos estáticos, no dan problemas y se pueden testear fácilmente.

Cómo testear funcionalidades del framework donde se usan fachadas. crear mocks de las fachadas y expectations de los mocks. Además veremos la diferencia que hay entre test de features y test unitarios cuando testeamos nuestros propios servicios y cómo es posible usar facades en test unitarios.

En el framework existen numerosos helpers que podemos usar para tener acceso a las mismas cosas que podemos usar mediante las fachadas. Veremos las diferencias que hay entre usar fachadas y usar helpers para el acceso a las mismas funcionalidades. Veremos que ambos se apoyan en el service container pero existen diferencias destacables sobre todo cuando hacemos tests unitarios.

En este vídeo vamos a desentrañar los secretos de las fachadas, analizando cómo funcionan de manera interna para entregarnos instancias de servicios a través del service container de Laravel. Esto nos ayudará a entender la arquitectura del framework en lo que respecta a las facades y los motivos por los que son tan testables.

Para finalizar el tema vamos a ver cómo crear nuestras propias fachadas, usando la utilidad de los real time facades que nos permite usar fachadas de nuestros propios servicios, sin que tengamos en realidad que hacer nada más que importarlas de un namespace determinado. Veremos además que si usamos los servicios como fachadas tenemos exactamente los mismos beneficios en el testing que si usásemos inyección de dependencias, ya que se sigue invocando por debajo el service container. Aunque hay matices que debes de conocer y también estudiaremos.

En el paso anterior vimos que no necesitamos crear nuestras propias fachadas si usamos las real time facades. No obstante si por lo que sea quieres tener facades reales, su implementación es verdaderamente sencilla, con los conceptos que hemos visto hasta ahora. Lo veremos con detalle paso por paso para que nadie se pierda.

Vamos a explicar qué son los Form Request y por qué nos pueden ayudar hacer controladores más ligeros, separando ciertas responsabilidades como son la validación y autorización.

Completamos el form request definimos el método autorize y un policy para delegar de manera centralizada de las tareas de autorización de las acciones sobre los modelos.

Necesitamos un segundo form request para la operación de update del controlador. Veremos cómo crearlo y cómo apoyarnos en las reglas y el policy.

Como hemos visto, lo ideal es tener dos form request para las operaciones de creación y actualización de los modelos. Sin embargo, eso nos hace repetir la mayor parte del código de las validaciones. Veremos cómo mejorar esta situación mediante un trait y cómo personalizar las validaciones con los campos que pueden cambiar entre edición e inserción.

En este vídeo hacemos una conclusión final a modo de repaso. Veremos cómo hemos aplicado los principios SOLID a lo largo del curso, mediante qué técnicas y piezas de software. Luego veremos otros principios aplicados y dónde se aplicaron.