Los proveedores de servicios son la parte central del inicio básico de una aplicación Laravel (bootstrapping). Tu propia aplicación, así como todos los servicios principales de Laravel son iniciados rápidamente usando proveedores de servicios.
Pero, ¿qué queremos decir por «inicio básico (bootstrapped)»? En general, nos referimos a registrar cosas, incluyendo registrar enlaces de contenedores de servicios, listeners de eventos, middleware e incluso rutas. Los proveedores de servicios son el lugar principal para configurar tu aplicación.
Si abres el archivo config/app.php incluido con Laravel, verás un arreglo providers. Estas son todas las clases de proveedores de servicios que serán cargados por tu aplicación. Observa que muchos de éstos son proveedores «diferidos», lo que significa que no serán cargados en cada solicitud, sino sólo cuando los servicios que proporcionan sean necesarios.
En este resumen aprenderás a escribir tus propios proveedores de servicio y registrarlos en tu aplicación de Laravel.
Escribiendo proveedores de servicios
Todos los proveedores de servicios extienden de la clase Illuminate\Support\ServiceProvider. La mayoría de los proveedores de servicio contienen un método register y boot. Dentro del método register, debes enlazar cosas sólo al contenedor de servicios. Nunca debes tratar de registrar ningún listener de eventos, rutas o cualquier otra pieza de funcionalidad dentro del método register.
La línea de comandos Artisan puede generar un nuevo proveedor mediante el comando make:provider:
El contenedor de servicios de Laravel es una herramienta poderosa para administrar dependencias de clases y realizar inyección de dependencias. La inyección de dependencias es una frase bonita para básicamente decir: las dependencias de clases son «inyectadas» en la clase mediante el constructor o, en algunos casos, métodos «setter».
Demos un vistazo a un ejemplo sencillo:
<?php
namespace App\Http\Controllers;
use App\Http\Controllers\Controller;
use App\Repositories\UserRepository;
use App\User;
class UserController extends Controller
{
/**
* The user repository implementation.
*
* @var UserRepository
*/
protected $users;
/**
* Create a new controller instance.
*
* @param UserRepository $users
* @return void
*/
public function __construct(UserRepository $users)
{
$this->users = $users;
}
/**
* Show the profile for the given user.
*
* @param int $id
* @return Response
*/
public function show($id)
{
$user = $this->users->find($id);
return view('user.profile', ['user' => $user]);
}
}
En este ejemplo, UserController necesita retornar usuarios desde un origen de datos. Así que, inyectaremos un servicio que sea capaz de retornar los usuarios. En este contexto, nuestro UserRepository probablemente use Eloquent para retornar la información de los usuarios desde la base de datos. Sin embargo, dado que el repositorio es inyectado, seremos capaces de cambiarlo fácilmente con otra implementación. También seremos capaces de «simular» o crear una implementación de ejemplo de UserRepository al probar nuestra aplicación.
Un conocimiento profundo del contenedor de servicios de Laravel es esencial para construir aplicaciones grandes y poderosas así como también contribuir al núcleo de Laravel.
Al usar cualquier herramienta en el «mundo real», te sientes más cómodo si entiendes cómo funciona esa herramienta. El desarrollo de aplicaciones no es diferente. Cuando entiendes cómo funcionan tus herramientas de desarrollo, te sientes más cómodo y seguro usándolas.
El objetivo de este documento es darte un buen resumen sobre cómo funciona el framework Laravel. Al conocer mejor el framework, todo lo demás se siente menos «mágico» y te sentirás más cómodo construyendo tus aplicaciones. Si no entiendes todos los términos de una sola vez, ¡no te desesperes! Sólo trata de obtener una comprensión básica de lo que está sucediendo y tus conocimientos crecerán a medida que explores otras secciones de la documentación.
Resumen del ciclo de vida
Lo primero
El punto de entrada para todas las solicitudes a una aplicación de Laravel es el archivo public/index.php. Todas las solicitudes son dirigidas a este archivo por la configuración de tu servidor web (Apache / Nginx). El archivo index.php no contiene mucho código. En su lugar, es un punto de partida para cargar el resto del framework.
El archivo index.php carga la definición de autocarga generada por Composer, y luego retorna una instancia de la aplicación de Laravel desde el script bootstrap/app.php. La primera acción tomada por Laravel es crear una instancia de la aplicación / contenedor de servicios.
Una vez que estés listo para hacer deploy de tu aplicación de Laravel a producción, deberías considerar algunos aspectos importantes para hacer que tu aplicación se ejecute de la forma más eficientemente posible. En este documento, vamos a cubrir muy buenos puntos para hacer que tu aplicación de Laravel sea desplegada correctamente.
Configuración del servidor
Nginx
Si estás haciendo deploy de tu aplicación hacia un servidor que está ejecutando Nginx, puedes utilizar el siguiente archivo de configuración como punto de inicio para configurar tu servidor web. Principalmente, este archivo tendrá que ser personalizado dependiendo de la configuración de tu servidor. Si deseas asistencia en la administración de tu servidor, considera utilizar un servicio como Laravel Forge:
La estructura por defecto de aplicación de Laravel está pensada para proporcionar un buen punto de inicio para aplicaciones grandes y pequeñas. Pero, eres libre de organizar tu aplicación como quieras. Laravel no impone casi ninguna restricción sobre dónde una clase es ubicada – siempre y cuando Composer pueda cargar automáticamente la clase.
¿Donde está el directorio de modelos?
Al comenzar con Laravel, muchos desarrolladores son confundidos por la falta de un directorio models. Sin embargo, la falta de dicho directorio es intencional. Encontramos la palabra «models» ambigua dado que significa muchas cosas diferentes para muchas personas. Algunos desarrolladores se refieren al «modelo» de una aplicación como la totalidad de toda su lógica de negocio, mientras que otros se refieren a los «modelos» como clases que interactúan con una base de datos relacional.
Por esta razón, elegimos ubicar los modelos de Eloquent por defecto en el directorio app y permitir al desarrollar ubicarlos en algún otro sitio si así lo eligen.
Directorio Raíz
Directorio App
El directorio app contiene el código principal de tu aplicación. Exploraremos este directorio con más detalle pronto; sin embargo, casi todas las clases en tu aplicación estarán en este directorio.
Directorio Bootstrap
El directorio bootstrap contiene el archivo app.php que maqueta el framework. Este directorio también almacena un directorio cache que contiene archivos generados por el framework para optimización de rendimiento como los archivos de caché de rutas y servicios.
Directorio Config
El directorio config, como el nombre implica, contiene todos los archivos de configuración de tu aplicación. Es una buena idea leer todos estos archivos y familiarizarte con todas las opciones disponibles para ti.
Directorio Database
El directorio database contiene las migraciones de tu base de datos, model factories y seeders. Si lo deseas, puedes también usar este directorio para almacenar una base de datos SQLite.
Directorio Public
El directorio public contiene el archivo index.php, el cual es el punto de acceso para todas las solicitudes que llegan a tu aplicación y configura la autocarga. Este directorio también almacena tus assets, tales como imágenes, JavaScript y CSS.
Directorio Resources
El directorio resources contiene tus vistas así como también tus assets sin compilar tales como LESS, Sass o JavaScript. Este directorio también almacena todos tus archivos de idiomas.
Directorio Routes
El directorio routes contiene todas las definiciones de rutas para tu aplicación. Por defecto, algunos archivos de rutas son incluidos con Laravel: web.php, api.php, console.php y channels.php.
El archivo web.php contiene rutas que RouteServiceProvider coloca en el grupo de middleware web, que proporciona estado de sesión, protección CSRF y encriptación de cookies. Si tu aplicación no ofrece una API sin estado, todas tus rutas probablemente serán definidas en el archivo web.php.
El archivo api.php contiene rutas que RouteServiceProvider coloca en el grupo de middleware api, que proporcionan limitación de velocidad. Estas rutas están pensadas para no tener estado, así que las solicitudes que llegan a la aplicación a través de estas rutas están pensadas para ser autenticadas mediante tokens y no tendrán acceso al estado de sesión.
El archivo console.php es donde puedes definir todos los comandos de consola basados en Closures de tu aplicación. Cada Closure está enlazado a una instancia de comando permitiendo una forma simple de interactuar con los métodos de entrada y salida de cada comando. Aunque este archivo no define ninguna ruta HTTP, sí define puntos de entrada en consola (rutas) a tu aplicación.
El archivo channels.php es donde puedes registrar todos los canales de transmisión de eventos que tu aplicación soporta.
Directorio Storage
El directorio storage contiene tus plantillas compiladas de Blade, sesiones basadas en archivos, archivos de caché y otros archivos generados por el framework. Este directorio está segregado en los directorios app, framework y logs. El directorio app puede ser usado para almacenar cualquier archivo generado por tu aplicación. El directorio framework es usado para almacenar archivos generados por el framework y caché. Finalmente, el directorio logs contiene los archivos de registros de tu aplicación.
El directorio storage/app/public puede ser usado para almacenar archivos generados por el usario, tales como imágenes de perfil, que deberían ser accesibles públicamente. Debes crear un enlace simbólico en public/storage que apunte a este directorio. Puedes crear el enlace usando el comando php artisan storage:link.
El Directorio Tests
El directorio tests contiene tus pruebas automatizadas. Una prueba de ejemplo de PHPUnit es proporcionada. Cada clase de prueba debe tener el sufijo Test. Puedes ejecutar tus pruebas usando los comandos phpunit o php vendor/bin/phpunit.
Directorio Vendor
El directorio vendor contiene tus dependencias de Composer.
Directorio App
La mayoría de tu aplicación está almacenada en el directorio app. Por defecto, este directorio está regido por el espacio de nombre App y es cargado automáticamente por Composer usando el estándar de autocarga PSR-4.
El directorio app contiene una variedad de directorios adicionales tales como Console, Http y Providers. Piensa en los directorios Console y Http como si proporcionaran una API al núcleo de tu aplicación, pero no contienen lógica de la aplicación como tal. En otras palabras, son dos formas de emitir comandos a tu aplicación. El directorio Console contiene todos tus comandos de Artisan, mientras que el directorio Http contiene tus controladores, middleware y solicitudes.
Una variedad de otros directorios serán generados dentro del directorio app cuando uses los comandos make de Artisan para generar clases. Así que, por ejemplo, el directorio app/Jobs no existirá hasta que ejecutes el comando de Artisan make:job para generar una clase job.
Muchas de las clases en el directorio app pueden ser generadas por Artisan mediante comandos. Para ver los comandos disponibles, ejecuta el comando php artisan list make en tu terminal.
Directorio Broadcasting
El directorio Broadcasting contiene todas las clases de canales de broadcast de tu aplicación. Estas clases son generadas usando el comando make:channel. Este directorio no existe por defecto, pero será creado para ti cuando crees tu primer canal. Para aprender más sobre canales, revisa la documentación sobre broadcasting de eventos.
El Directorio Console
El directorio Console contiene todos los comandos personalizados de Artisan para tu aplicación. Estos comandos pueden ser generados usando el comando make:command. Este directorio también almacena el kernel de tu consola, que es donde tus comandos personalizados de Artisan son registrados y tus tareas programadas son definidas.
Directorio Events
Este directorio no existe por defecto, pero será creado para ti por los comandos de Artisan event:generate y make:event. El directorio Events almacena clases de eventos. Los eventos pueden ser usados para alertar a otras partes de tu aplicación que una acción dada ha ocurrido, proporcionando una gran cantidad de flexibilidad y desacoplamiento.
Directorio Exceptions
El directorio Exceptions contiene el manejador de excepciones de tu aplicación y también es un buen lugar para colocar cualquier excepción lanzada por tu aplicación. Si te gustaría personalizar cómo las excepciones son mostradas o renderizadas, debes modificar la clase Handler en este directorio.
Directorio Http
El directorio Http contiene tus controladores, middleware y form requests. Casi toda la lógica para manejar las solicitudes que llegan a tu aplicación serán colocadas en este directorio.
Directorio Jobs
Este directorio no existe por defecto, pero será creado para ti si ejecutas el comando de Artisan make:job. El directorio Jobs almacena las colas de trabajos para tu aplicación. Los trabajos pueden ser encolados por tu aplicación o ejecutados sincrónicamente dentro del ciclo de vida actual de la solicitud. Los trabajos que son ejecutados sincrónicamente durante la solicitud actual son algunas veces referidos como «comandos» dado que son una implementación del patrón de comandos.
Directorio Listeners
Este directorio no existe por defecto, pero será creado para ti si ejecutas los comandos de Artisan event:generate o make:listener. El directorio Listeners contiene las clases que manejan tus eventos. Los listeners de eventos reciben una instancia de evento y realizan la lógica en respuesta al evento siendo ejecutado. Por ejemplo, un evento UserRegistered puede ser manejado por un listener SendWelcomeEmail.
Directorio Mail
Este directorio no existe por defecto, pero será creado para ti si ejecutas el comando de Artisan make:mail. El directorio Mail contiene todas tus clases que representan correos electrónicos enviados por tu aplicación. Los objetos de correo te permiten encapsular toda la lógica para construir un correo en una única y sencilla clase, que puede ser enviada usando el método Mail::send.
Directorio Notifications
Este directorio no existe por defecto, pero será creado para ti si ejecutas el comando de Artisan make:notification. El directorio Notifications contiene todas las notificaciones «transaccionales» que son enviadas por tu aplicación, tales como notificaciones sencillas sobre eventos que ocurren dentro de tu aplicación. Las características de notifcaciones de Laravel abstrae el envío de notificaciones sobre una variedad de drivers como email, Slack, SMS o almacenadas en la base de datos.
Directorio Policies
Este directorio no existe por defecto, pero será creado para ti si ejecutas el comando de Artisan make:policy. El directorio Policies contiene las clases de las políticas de autorización de tu aplicación. Las políticas son usadas para determinar si un usuario puede realizar una acción dada contra un recurso. Para más información, revisa la documentación sobre autorización.
Directorio Providers
El directorio Providers contiene todos los proveedores de servicios para tu aplicación. Los proveedores de servicios maquetan tu aplicación al enlazar servicios en el contenedor de servicios, registrando eventos o realizando cualquier otra tarea para preparar tu aplicación para solicitudes entrantes.
En una aplicación de Laravel nueva, este directorio ya contendrá algunos proveedores. Eres libre de agregar tus propios proveedores a este directorio según sea necesario.
Directorio Rules
Este directorio no existe por defecto, pero será creado para ti si ejecutas el comando de Artisan make:rule. El directorio Rules contiene los objetos para las reglas de validación personalizadas de tu aplicación. Las reglas son usadas para encapsular lógica de validación complicada en un simple objeto. Para más información, revisa la documentación sobre validación.
Valet es un entorno de desarrollo minimalista de Laravel para Mac. No requiere de Vagrant ni de modificar el archivo de configuración /etc/hosts. Incluso permite compartir tus sitios a través de túneles locales. Sí, también nos gusta
Laravel Valet configura tu Mac para que siempre inicie el servicio de Nginx en segundo plano al iniciar tu computadora. Después, usando DnsMasq, Valet actuará como servidor proxy, procesando todas las peticiones en el dominio *.test apuntando a los sitios instalados en tu máquina local.
En otras palabras, es un entorno de desarrollo de Laravel sorprendentemente rápido y solamente utiliza cerca de 7MB de RAM. Laravel Valet no está pensado para ser un reemplazo de Vagrant o Homestead, en su lugar presenta una alternativa flexible y rápida, lo cual es una buena opción para quienes tengan una cantidad limitada de RAM.
Por defecto, Valet brinda soporte para las siguientes tecnologías, pero no está limitado a sólo ellas:
Laravel se ha esforzado en hacer que toda la experiencia del desarrollo de PHP sea placentera, incluyendo el entorno de desarrollo local. Vagrant provee una manera simple y elegante de administrar y aprovisionar máquinas virtuales.
Laravel Homestead es el box de Vagrant pre-empaquetado oficial que brinda un maravilloso entorno de desarrollo sin la necesidad de que tengas que instalar PHP, un servidor web, ni ningún otro software de servidor en tu máquina local. ¡Basta de preocuparte por estropear tu sistema operativo! Los boxes de Vagrant son completamente desechables. Si algo sale mal, simplemente puedes destruir y volver a crear el box en cuestión de minutos.
Homestead puede ejecutarse en sistemas Windows, Mac y Linux e incluye Nginx, PHP, MySQL, PostgreSQL, Redis, Memcached, Node y todas las demás herramientas que necesitas para desarrollar aplicaciones de Laravel sorprendentes.
Si estás utilizando Windows, puede que necesites habilitar la virtualización por hardware (VT-x). Usualmente puede habilitarse en el BIOS. Si estás utilizando Hyper-V en un sistema UEFI puede que requieras también deshabilitar Hyper-V para poder acceder a VT-x.
Todos los archivos de configuración para el framework Laravel están almacenados en el directorio config. Cada opción está documentada, así que no dudes en consultar los archivos y familiarizarte con las opciones disponibles para ti.
Configuración del entorno
A menudo es útil tener diferentes valores de configuración basados en el entorno en el que se ejecuta la aplicación. Por ejemplo, es posible que desees utilizar localmente un driver de caché diferente del que quieras usar en un servidor para producción.
Para hacer esto sencillo, Laravel utiliza la librería de PHP DotEnv por Vance Lucas. En una nueva instalación de Laravel, el directorio raíz de tu aplicación contendrá un archivo .env.example. Si instalas Laravel por medio de Composer, este archivo será renombrado automáticamente a .env. De lo contrario, deberás renombrar el archivo manualmente.
Tu archivo .env deberá omitirse en el sistema de control de versiones de tu aplicación, ya que cada desarrollador / servidor que usa tu aplicación puede requerir una configuración de entorno diferente. Además, esto sería un riesgo de seguridad en caso de que un intruso obtenga acceso al repositorio de control de versiones de tu aplicación, ya que cualquier credencial confidencial se expondría.
Si estás desarrollando con un equipo, es posible que desees continuar incluyendo el archivo .env.example en tu aplicación. Al poner valores de ejemplo (placeholder) en el archivo de configuración .env.example, otros desarrolladores en tu equipo podrán ver claramente cuáles variables de entorno se necesitan para ejecutar tu aplicación. También puedes crear un archivo .env.testing. Este archivo sobrescribirá el archivo .env al ejecutar pruebas con PHPUnit o al ejecutar comandos de Artisan con la opción --env=testing.
Cualquier variable en tu archivo .env puede ser anulada por variables de entorno externas tales como variables de entorno de nivel de servidor o de nivel de sistema.
Si estás comenzando con Laravel, te recomendamos empezar con nuestro curso Primeros pasos con Laravel 6 y luego regresar a la documentación.
Requisitos del servidor
El framework Laravel tiene algunos requisitos del sistema. Todos estos requisitos son cubiertos por la máquina virtual Laravel Homestead, así que es altamente recomendable que uses Homestead como tu entorno local de desarrollo de Laravel.
Sin embargo, si no estás utilizando Homestead, deberás asegurarte de que tu servidor cumpla con los siguientes requisitos:
PHP >= 7.2.0
Extensión BCMath para PHP
Extensión Ctype para PHP
Extensión Fileinfo para PHP
Extensión JSON para PHP
Extensión Mbstring para PHP
Extensión OpenSSL para PHP
Extensión PDO para PHP
Extensión Tokenizer para PHP
Extensión XML para PHP
La instalación de Laravel en un subdirectorio no está soportada.
Cuando ya tenemos una aplicación de Laravel en producción, puede que necesitemos aplicar cambios que afectarían su funcionamiento mientras se realiza la actualización. Para esos momentos, Laravel nos provee una manera sencilla de poner en modo mantenimiento la aplicación mientras hacemos los cambios. Veamos cómo podemos activarlo.
Styde usa cookies para guardar tus preferencias y para seguimiento anónimo AceptarLeer más
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
