MVC (Laravel) donde agregar lógica

Digamos que cada vez que hago una operación CRUD o modifico una relación de una manera específica, también quiero hacer otra cosa. Por ejemplo, cada vez que alguien publica una publicación, también quiero guardar algo en una tabla para análisis. Quizás no sea el mejor ejemplo, pero en general hay mucha de esta funcionalidad "agrupada".

Normalmente veo este tipo de lógica en los controladores. Eso está muy bien hasta que quieras reproducir esta funcionalidad en muchos lugares. Cuando comienzas a entrar en parciales, crear una API y generar contenido ficticio, se convierte en un problema para mantener las cosas SECAS.

Las formas en que he visto administrar esto son eventos, repositorios, bibliotecas y agregar a modelos. Aquí están mis entendimientos de cada uno:

Servicios: aquí es donde la mayoría de las personas probablemente pondrían este código. Mi principal problema con los servicios es que a veces es difícil encontrar una funcionalidad específica en ellos y siento que se olvidan cuando las personas se centran en usar Eloquent. ¿Cómo sabría que necesito llamar a un método publishPost()en una biblioteca cuando puedo hacerlo $post->is_published = 1?

La única condición en la que veo que esto funciona bien es si SOLO usa los servicios (e idealmente hace que Eloquent sea inaccesible de alguna manera desde todos los controladores).

En última instancia, parece que esto solo crearía un montón de archivos innecesarios adicionales si sus solicitudes generalmente siguen la estructura de su modelo.

Repositorios: por lo que entiendo, esto es básicamente como un servicio, pero hay una interfaz para que pueda cambiar entre ORM, que no necesito.

Eventos: veo esto como el sistema más elegante en cierto sentido porque sabe que los eventos de su modelo siempre se llamarán con métodos Eloquent, por lo que puede escribir sus controladores como lo haría normalmente. Sin embargo, puedo ver que estos se vuelven desordenados y si alguien tiene ejemplos de proyectos grandes que usan eventos para el acoplamiento crítico, me gustaría verlo.

Modelos: Tradicionalmente, tenía clases que realizaban CRUD y también manejaban el acoplamiento crítico. Esto realmente facilitó las cosas porque sabía que todas las funcionalidades relacionadas con CRUD +, lo que sea que tuviera que hacer con él, estaban allí.

Simple, pero en la arquitectura MVC esto normalmente no es lo que veo hecho. En cierto sentido, prefiero esto a los servicios, ya que es un poco más fácil de encontrar y hay menos archivos de los que hacer un seguimiento. Sin embargo, puede ser un poco desorganizado. Me gustaría escuchar las desventajas de este método y por qué la mayoría de las personas no parecen hacerlo.

¿Cuáles son las ventajas / desventajas de cada método? ¿Me estoy perdiendo de algo?

Creo que todos los patrones / arquitecturas que presenta son muy útiles siempre que siga los principios de SOLID .

Para saber dónde agregar lógica , creo que es importante hacer referencia al Principio de responsabilidad única . Además, mi respuesta considera que estás trabajando en un proyecto mediano / grande. Si es un proyecto de tirar algo en una página , olvide esta respuesta y agréguela a los controladores o modelos.

La respuesta corta es: dónde tiene sentido para usted (con servicios) .

La respuesta larga:

Controladores : ¿Cuál es la responsabilidad de los Controladores? Claro, puede poner toda su lógica en un controlador, pero ¿es esa la responsabilidad del controlador? No lo creo.

Para mí, el controlador debe recibir una solicitud y devolver datos y este no es el lugar para poner validaciones, llamar a métodos db, etc.

Modelos : ¿Es este un buen lugar para agregar lógica como enviar un correo electrónico de bienvenida cuando un usuario se registra o actualiza el recuento de votos de una publicación? ¿Qué sucede si necesita enviar el mismo correo electrónico desde otro lugar en su código? ¿Creas un método estático? ¿Qué pasa si ese correo electrónico necesita información de otro modelo?

Creo que el modelo debería representar una entidad. Con laravel, sólo utilizar la clase modelo para agregar cosas como fillable, guarded, tabley las relaciones (esto es porque uso el patrón de repositorio, de lo contrario el modelo también tendría los save, update, findmétodos, etc).

Repositorios (patrón de repositorio) : Al principio estaba muy confundido por esto. Y, como usted, pensé "bueno, uso MySQL y eso es todo".

Sin embargo, he equilibrado los pros y los contras de usar el Patrón de repositorio y ahora lo uso. Creo que ahora , en este mismo momento, solo necesitaré usar MySQL. Pero, si dentro de tres años necesito cambiar a algo como MongoDB, la mayor parte del trabajo está hecho. Todo a expensas de una interfaz adicional y a $app->bind(«interface», «repository»).

Eventos ( patrón de observador ): los eventos son útiles para cosas que se pueden lanzar en cualquier clase en cualquier momento dado. Piense, por ejemplo, en enviar notificaciones a un usuario. Cuando lo necesita, activa el evento para enviar una notificación a cualquier clase de su aplicación. Luego, puede tener una clase como UserNotificationEventsesa que maneje todos sus eventos activados para las notificaciones de los usuarios.

Servicios : hasta ahora, tiene la opción de agregar lógica a los controladores o modelos. Para mí, tiene sentido agregar la lógica dentro de los Servicios . Seamos realistas, Servicios es un nombre elegante para las clases. Y puede tener tantas clases como tenga sentido dentro de su aplicación.

Tome este ejemplo: Hace poco desarrollé algo así como los Formularios de Google. Empecé con una CustomFormServicey terminó con CustomFormService, CustomFormRender, CustomFieldService, CustomFieldRender, CustomAnswerServicey CustomAnswerRender. ¿Por qué? Porque tenía sentido para mí. Si trabaja con un equipo, debe poner su lógica donde tenga sentido para el equipo.

La ventaja de usar Servicios vs Controladores / Modelos es que no está limitado por un solo Controlador o un solo Modelo. Puede crear tantos servicios como sea necesario según el diseño y las necesidades de su aplicación. Agregue a eso la ventaja de llamar a un Servicio dentro de cualquier clase de su aplicación.

Esto es largo, pero me gustaría mostrarle cómo he estructurado mi aplicación:

app/
    controllers/
    MyCompany/
        Composers/
        Exceptions/
        Models/
        Observers/
        Sanitizers/
        ServiceProviders/
        Services/
        Validators/
    views
    (...)

Yo uso cada carpeta para una función específica. Por ejemplo, el Validatorsdirectorio contiene una BaseValidatorclase responsable de procesar la validación, basada en $rulesy $messagesde validadores específicos (generalmente uno para cada modelo). Podría poner fácilmente este código dentro de un Servicio, pero tiene sentido para mí tener una carpeta específica para esto, incluso si solo se usa dentro del servicio (por ahora).

Le recomiendo que lea los siguientes artículos, ya que podrían explicarle las cosas un poco mejor:

Rompiendo el molde por Dayle Rees (autor de CodeBright): Aquí es donde lo armé todo, a pesar de que cambié algunas cosas para satisfacer mis necesidades.

Desacoplar su código en Laravel utilizando repositorios y servicios de Chris Goosey: esta publicación explica bien qué es un servicio y el patrón de repositorio y cómo encajan entre sí.

Los Laracasts también tienen los Repositorios de responsabilidad simple y simplificada, que son buenos recursos con ejemplos prácticos (aunque tenga que pagar).

Quería publicar una respuesta a mi propia pregunta. Podría hablar sobre esto durante días, pero voy a tratar de publicar esto rápidamente para asegurarme de que lo levante.

Terminé utilizando la estructura existente que proporciona Laravel, lo que significa que mantuve mis archivos principalmente como Modelo, Vista y Controlador. También tengo una carpeta de Bibliotecas para componentes reutilizables que no son realmente modelos.

NO ENVOLVÉ MIS MODELOS EN SERVICIOS / BIBLIOTECAS . Todas las razones proporcionadas no me convencieron al 100% del beneficio de usar los servicios. Si bien puedo estar equivocado, por lo que puedo ver, solo resultan en toneladas de archivos adicionales casi vacíos que necesito crear y cambiar cuando trabajo con modelos y también reducen realmente el beneficio de usar elocuencia (especialmente cuando se trata de RECUPERAR modelos , p. ej., utilizando paginación, ámbitos, etc.).

Puse la lógica comercial EN LOS MODELOS y accedo directamente desde mis controladores elocuentes. Utilizo una serie de enfoques para asegurarme de que no se omita la lógica empresarial:

• Accesores y mutadores: Laravel tiene excelentes accesores y mutadores. Si deseo realizar una acción cada vez que una publicación se mueve de borrador a publicado, puedo llamar a esto creando la función setIsPublishedAttribute e incluyendo la lógica allí
• Anulación de Crear / Actualizar, etc.: siempre puede anular los métodos Eloquent en sus modelos para incluir una funcionalidad personalizada. De esa manera, puede llamar a la funcionalidad en cualquier operación CRUD. Editar: creo que hay un error al anular la creación en versiones más recientes de Laravel (por lo que uso eventos ahora registrados en el arranque)
• Validación: conecto mi validación de la misma manera, por ejemplo, ejecutaré la validación anulando las funciones CRUD y también los accesores / mutadores si es necesario. Vea Esensi o dwightwatson / validating para más información.
• Métodos Mágicos: uso los métodos __get y __set de mis modelos para conectarlos a la funcionalidad cuando sea apropiado
• Elocuente extendido: si hay una acción que le gustaría realizar en todas las actualizaciones / crear, incluso puede extender elocuente y aplicarlo a múltiples modelos.
• Eventos: Este es un lugar directo y generalmente acordado para hacer esto también. El mayor inconveniente con los eventos, creo, es que las excepciones son difíciles de rastrear (podría no ser el nuevo caso con el nuevo sistema de eventos de Laravel). También me gusta agrupar mis eventos por lo que hacen en lugar de cuando se los llama ... por ejemplo, tener un suscriptor de MailSender que escucha los eventos que envían correo.
• Agregar eventos Pivot / BelongsToMany: Una de las cosas con las que luché por más tiempo fue cómo asociar el comportamiento a la modificación de las relaciones belongToMany. Por ejemplo, realizar una acción cada vez que un usuario se une a un grupo. Ya casi termino de pulir una biblioteca personalizada para esto. ¡Todavía no lo he publicado pero es funcional! Intentaremos publicar un enlace pronto. EDITAR Terminé convirtiendo todos mis pivotes en modelos normales y mi vida ha sido mucho más fácil ...

Abordar las preocupaciones de las personas con el uso de modelos:

• Organización: Sí, si incluye más lógica en los modelos, pueden ser más largos, pero en general he descubierto que el 75% de mis modelos siguen siendo bastante pequeños. Si elijo organizar los más grandes, puedo hacerlo usando rasgos (por ejemplo, crear una carpeta para el modelo con algunos archivos más como PostScopes, PostAccessors, PostValidation, etc., según sea necesario). Sé que esto no es necesariamente para qué sirven los rasgos, pero este sistema funciona sin problemas.

Nota adicional: Siento que envolver sus modelos en servicios es como tener una navaja suiza, con muchas herramientas, y construir otra navaja alrededor que básicamente haga lo mismo. Sí, a veces es posible que desee cortar con cinta una cuchilla o asegurarse de que dos cuchillas se usen juntas ... pero generalmente hay otras formas de hacerlo ...

CUANDO UTILIZA LOS SERVICIOS : Este artículo articula muy bien GRANDES ejemplos de cuándo usar los servicios ( pista: no es muy frecuente ). Básicamente, dice que cuando su objeto usa múltiples modelos o modelos en partes extrañas de su ciclo de vida , tiene sentido. http://www.justinweiss.com/articles/where-do-you-put-your-code/

Lo que suelo hacer para crear la lógica entre controladores y modelos es crear una capa de servicio . Básicamente, este es mi flujo para cualquier acción dentro de mi aplicación:

1. El controlador obtiene la acción solicitada por el usuario y los parámetros enviados y delega todo a una clase de servicio.
2. La clase de servicio realiza toda la lógica relacionada con la operación: validación de entrada, registro de eventos, operaciones de base de datos, etc.
3. El modelo contiene información de campos, transformación de datos y definiciones de validaciones de atributos.

Así es como lo hago:

Este es el método de un controlador para crear algo:

public function processCreateCongregation()
{
    // Get input data.
    $congregation                 = new Congregation;
    $congregation->name           = Input::get('name');
    $congregation->address        = Input::get('address');
    $congregation->pm_day_of_week = Input::get('pm_day_of_week');
    $pmHours                      = Input::get('pm_datetime_hours');
    $pmMinutes                    = Input::get('pm_datetime_minutes');
    $congregation->pm_datetime    = Carbon::createFromTime($pmHours, $pmMinutes, 0);

    // Delegates actual operation to service.
    try
    {
        CongregationService::createCongregation($congregation);
        $this->success(trans('messages.congregationCreated'));
        return Redirect::route('congregations.list');
    }
    catch (ValidationException $e)
    {
        // Catch validation errors thrown by service operation.
        return Redirect::route('congregations.create')
            ->withInput(Input::all())
            ->withErrors($e->getValidator());
    }
    catch (Exception $e)
    {
        // Catch any unexpected exception.
        return $this->unexpected($e);
    }
}

Esta es la clase de servicio que realiza la lógica relacionada con la operación:

public static function createCongregation(Congregation $congregation)
{
    // Log the operation.
    Log::info('Create congregation.', compact('congregation'));

    // Validate data.
    $validator = $congregation->getValidator();

    if ($validator->fails())
    {
        throw new ValidationException($validator);
    }

    // Save to the database.
    $congregation->created_by = Auth::user()->id;
    $congregation->updated_by = Auth::user()->id;

    $congregation->save();
}

Y este es mi modelo:

class Congregation extends Eloquent
{
    protected $table = 'congregations';

    public function getValidator()
    {
        $data = array(
            'name' => $this->name,
            'address' => $this->address,
            'pm_day_of_week' => $this->pm_day_of_week,
            'pm_datetime' => $this->pm_datetime,
        );

        $rules = array(
            'name' => ['required', 'unique:congregations'],
            'address' => ['required'],
            'pm_day_of_week' => ['required', 'integer', 'between:0,6'],
            'pm_datetime' => ['required', 'regex:/([01]?[0-9]|2[0-3]):[0-5]?[0-9]:[0-5][0-9]/'],
        );

        return Validator::make($data, $rules);
    }

    public function getDates()
    {
        return array_merge_recursive(parent::getDates(), array(
            'pm_datetime',
            'cbs_datetime',
        ));
    }
}

Para obtener más información sobre esta forma, utilizo para organizar mi código para una aplicación Laravel: https://github.com/rmariuzzo/Pitimi

En mi opinión, Laravel ya tiene muchas opciones para que almacene su lógica de negocios.

Respuesta corta:

• Use los Requestobjetos de laravel para validar automáticamente su entrada y luego persista los datos en la solicitud (cree el modelo). Como todas las entradas de los usuarios están directamente disponibles en la solicitud, creo que tiene sentido realizar esto aquí.
• Use los Jobobjetos de laravel para realizar tareas que requieren componentes individuales, luego simplemente envíelos. Creo que Jobabarcan clases de servicio. Realizan una tarea, como la lógica empresarial.

Respuesta larga (er):

Use repositorios cuando sea necesario: los repositorios están obligados a sobrebloquearse, y la mayoría de las veces, simplemente se usan como un accessormodelo. Siento que definitivamente tienen algún uso, pero a menos que esté desarrollando una aplicación masiva que requiera esa cantidad de flexibilidad para poder deshacerse por completo de laravel, manténgase alejado de los repositorios. Te lo agradecerás más tarde y tu código será mucho más sencillo.

Pregúntese si existe la posibilidad de que vaya a cambiar los marcos PHP o a un tipo de base de datos que no sea compatible con laravel.

Si su respuesta es "Probablemente no", no implemente el patrón de repositorio.

Además de lo anterior, no coloque un patrón encima de un ORM excelente como Eloquent. Solo está agregando complejidad que no es necesaria y no lo beneficiará en absoluto.

Utilice los servicios con moderación: las clases de servicios para mí son solo un lugar para almacenar la lógica empresarial para realizar una tarea específica con sus dependencias dadas. Laravel los tiene listos para usar, llamados 'Empleos', y tienen mucha más flexibilidad que una clase de Servicio personalizada.

Siento que Laravel tiene una solución completa para el MVCproblema lógico. Es solo una cuestión u organización.

Ejemplo:

Solicitud :

namespace App\Http\Requests;

use App\Post;
use App\Jobs\PostNotifier;
use App\Events\PostWasCreated;
use App\Http\Requests\Request;

class PostRequest extends Request
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true;
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'title'       => 'required',
            'description' => 'required'
        ];
    }

    /**
     * Save the post.
     *
     * @param Post $post
     *
     * @return bool
     */
    public function persist(Post $post)
    {
        if (!$post->exists) {
            // If the post doesn't exist, we'll assign the
            // post as created by the current user.
            $post->user_id = auth()->id();
        }

        $post->title = $this->title;
        $post->description = $this->description;

        // Perform other tasks, maybe fire an event, dispatch a job.

        if ($post->save()) {
            // Maybe we'll fire an event here that we can catch somewhere else that
            // needs to know when a post was created.
            event(new PostWasCreated($post));

            // Maybe we'll notify some users of the new post as well.
            dispatch(new PostNotifier($post));

            return true;
        }

        return false;
    }
}

Controlador :

namespace App\Http\Controllers;

use App\Post;
use App\Http\Requests\PostRequest;

class PostController extends Controller
{

   /**
    * Creates a new post.
    *
    * @return string
    */
    public function store(PostRequest $request)
    {
        if ($request->persist(new Post())) {
            flash()->success('Successfully created new post!');
        } else {
            flash()->error('There was an issue creating a post. Please try again.');
        }

        return redirect()->back();
    }

   /**
    * Updates a post.
    *
    * @return string
    */
    public function update(PostRequest $request, $id)
    {
        $post = Post::findOrFail($id);

        if ($request->persist($post)) {
            flash()->success('Successfully updated post!');
        } else {
            flash()->error('There was an issue updating this post. Please try again.');
        }

        return redirect()->back();
    }
}

En el ejemplo anterior, la entrada de la solicitud se valida automáticamente, y todo lo que necesitamos hacer es llamar al método de persistencia y pasar una nueva publicación. Creo que la legibilidad y la facilidad de mantenimiento siempre deben superar los patrones de diseño complejos e innecesarios.

Luego puede utilizar exactamente el mismo método de persistencia para actualizar las publicaciones, ya que podemos verificar si la publicación ya existe o no y realizar una lógica alternativa cuando sea necesario.