Crear mis propios Services Providers

Aprende a estructurar un paquete de rating en Laravel con un service provider sólido, interfaces claras y testing confiable. Verás cómo limpiar el esqueleto del paquete, tipar eventos y traits con contratos, y validar todo con Orchestra Testbench. El resultado: un diseño consistente y fácil de mantener.

¿Qué es un service provider en Laravel y por qué es el centro del paquete?

El service provider es el punto central donde se registran bindings, listeners y migrations. Aquí se orquesta cómo se integra el paquete con la aplicación base, asegurando un ciclo de vida claro para cada componente.

• Se partió de un template con un service provider ya creado.
• Se renombró a RatingServiceProvider y se ajustó el namespace a laraveles.
• Se eliminó un comando no usado y se limpió código innecesario.
• Se borró la carpeta resources por no tener vistas.
• Se mantuvo la carpeta migrations con su archivo correspondiente.

¿Cómo organizar el código del paquete de rating?

• Define un namespace claro: laraveles.
• Nombra el service provider de forma expresiva: RatingServiceProvider.
• Quita artefactos que no aporten: comandos y recursos sin uso.
• Conserva solo lo esencial para el dominio del rating.

¿Qué registran los service providers?

• Bindings para dependencias y contratos.
• Listeners para eventos de dominio.
• Migrations y archivos de configuración.

¿Cómo usar interfaces y traits para un rating consistente?

Para independizar el paquete de los modelos de la app principal, se crearon interfaces en la carpeta contracts. Esto permite tipar la lógica y evitar que se pasen modelos incorrectos.

¿Qué interfaces definen el contrato del rating?

• qualifier: representa modelos que pueden calificar. Expone la relación, verifica si ya calificó, crea calificaciones y las obtiene.
• ratable: representa modelos que pueden ser calificados. Define los mismos métodos del trait asociado.
• rating: para modelos que son calificables y también pueden calificar.

¿Qué cambios se aplican en eventos y traits?

• En los eventos ModelRate y ModelUnrated se tiparon propiedades y getters con qualifier y ratable.
• El trait can rate ahora recibe un ratable en sus métodos.
• Se renombró el trait a can be rated para mayor claridad.
• Se creó el trait rate que compone ambos comportamientos, garantizando reutilización.

// Combina capacidades de calificar y ser calificado
trait Rate {
    use CanBeRated, CanRate;
}

¿Cómo usar la configuración para el modelo rating?

Se reemplazó la referencia directa al modelo por configuración, haciendo el paquete más flexible.

// Lee el modelo desde la configuración del paquete
$model = config('rating.models.rating');

• Se usa el archivo de configuración: rating.models.rating.
• Así se desacopla el código del nombre de la clase concreta.

¿Cómo se configuró el testing con Orchestra Testbench?

Para validar el paquete sin una app Laravel completa se utilizó Orchestra Testbench. Esto permite cargar el service provider, setear configuración por defecto y preparar una base de datos en memoria para pruebas rápidas y aisladas.

• Dependencia: Orchestra Testbench para pruebas de paquetes de Laravel.
• En el archivo TestCase se carga el RatingServiceProvider; se corrigió un error de escritura en el nombre e importación.
• Método getEnvironmentSetup con valores de configuración por defecto.
• Método resetDatabase para limpiar la base de datos en memoria.
• Modelos y factories preparados: algunos implementan ambas interfaces, otros ninguna.
• Archivo rating.test con pruebas que cubren el comportamiento esperado del paquete.
• Se alcanzó 100% de coverage, con 22 tests y 63 asserts, todos pasando.
• En composer.json se agregó el autoload de la carpeta de tests.

¿Quieres aportar ideas o te quedó alguna duda sobre interfaces, traits o Testbench? Cuéntalo en los comentarios y seguimos la conversación.