Aprovecha los eventos de Eloquent para automatizar tareas críticas del ciclo de vida de tus modelos. Aquí verás cómo, al crear un producto, se genera una imagen con Faker y se asigna el usuario logueado; además, cómo preparar la migración para una nueva columna y por qué conviene mover esta lógica a un observer para mantener el modelo limpio.

¿Qué son los eventos de Eloquent y cómo se usan en el modelo?

Los eventos de Eloquent permiten capturar momentos del ciclo de vida de un modelo. La forma directa de usarlos es sobrescribir el método estático booted y engancharse al evento creating, que se ejecuta antes de crear la entidad. Así, el producto recibe una URL aleatoria para su imagen usando Faker y se asocia al usuario autenticado mediante el helper auth.

Puntos clave:

• booted: método estático para registrar eventos del modelo.
• creating: corre antes de insertar en base de datos.
• Faker con su factory y método create genera datos falsos.
• Relación created by: asocia el producto al usuario logueado con el helper auth y su método user.

Ejemplo dentro del modelo Product:

fullscreen
protected static function booted()
{
    static::creating(function ($product) {
        $faker = \Faker\Factory::create();

        // URL aleatoria para la imagen.
        $product->image_url = $faker->url;

        // Asociar el usuario que está logueado en la relación createdBy.
        $product->createdBy()->associate(auth()->user());
    });
}

¿Cómo preparar la base de datos con una migración segura?

Antes de probar, se necesita la columna en base de datos. La indicación es crear una migración que agregue el campo de tipo texto para la image_url y permitir nulos para no afectar productos existentes. Luego, completar el método down para poder hacer rollback si es necesario.

Pasos esenciales:

• Crear la migración y nombrarla claramente.
• Agregar columna image_url como text y nullable.
• Completar el método down para borrar la columna en caso de rollback.
• Ejecutar con el comando de migrate.

Migración de ejemplo:

fullscreen
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration {
    public function up(): void
    {
        Schema::table('productos', function (Blueprint $table) {
            $table->text('image_url')->nullable();
        });
    }

    public function down(): void
    {
        Schema::table('productos', function (Blueprint $table) {
            $table->dropColumn('image_url');
        });
    }
};

Y luego ejecutar:

fullscreen
php artisan migrate

¿Por qué mover la lógica a un observer de Eloquent?

Aunque es válido colocar esta lógica en el modelo, la recomendación final es migrarla a un observer para que el modelo quede lo más limpio posible. Con un observer, centralizas la lógica de eventos (creating, entre otros) fuera del modelo, manteniendo mejor separación de responsabilidades y un código más mantenible.

Beneficios al usar un observer:

• Modelo limpio: responsabilidades claras y menos acoplamiento.
• Organización: eventos reunidos en una sola clase.
• Escalabilidad: facilita extender reglas para más eventos.

Revisa la documentación oficial para crear el observer y mover toda la lógica de negocio allí. Después, estarás listo para la introducción al uso de queues y jobs.

¿Te quedó alguna duda sobre los eventos de Eloquent, Faker o la migración? Comenta y con gusto te ayudo a resolverla.